]> b7n0de

Germany kontakt@b7n0de.com

Security AUDIT agent decision receipt in-toto DSSE The architecture for auditing agent delegation and interactions proposed for the AUDIT effort names Interaction Records, Action Records and Authorization Transition Records, and leaves their encoding open. This document shows how an existing signed record, the decision receipt of the open-source proofbundle project, together with its companion outcome receipt, gives three such records exact bytes, a signature and digest bindings that a third party can check offline. The three cases are a human approval, a declined action and an executed action with its result. For each case the document maps the receipt members onto the record types of the architecture, states what the receipt adds and what it does not show, and gives an offline verification procedure. It states one requirement for approvals, that an approval is honoured at most once, also after the record of consumed approvals is rotated. Test vectors for all three cases, each with a counterexample, are included. This document defines no new format, predicate or registry.

Introduction The architecture of asks that auditing link user intent, delegation, authorization and execution, and treats authorization as a state that changes over time. Three of its four record types (its Section 5) matter here. Interaction Records capture user-facing events such as approvals and refusals, Action Records capture events at the boundary where an action took effect, and Authorization Transition Records capture changes in permission state. Its field names are placeholders (its Section 7), and a canonical data model is a work item (WI-1). An Auditor in that architecture does not trust the Agent (its Section 8), so a record helps only when a third party can check it. That needs exact bytes, a signature over them and bindings to inputs and evidence by digest. This document shows that the decision receipt of proofbundle , an in-toto Statement in a DSSE envelope , signed with Ed25519 over a payload in the serialization of , supplies them together with its companion outcome receipt . It does so for three cases that Agent Guard, the gate of the proofbundle plugin for two coding agent hosts, produces ():

1. a human approval of one action (an Interaction Record of an approval and an Authorization Transition Record with the trigger user_approval);
2. a declined action, with its reason and without an effect;
3. an executed action with its result (an Action Record).

The document maps and verifies. It does not propose the decision receipt as the data model of the architecture and does not change the receipts it describes.

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.

Terms

Decision receipt, outcome receipt:

A DSSE envelope whose payload is an in-toto Statement v1 with the predicate type https://b7n0de.com/proofbundle/predicates/decision-receipt/v0.1 or https://b7n0de.com/proofbundle/predicates/action-outcome/v0.1.

Payload bytes:

The bytes obtained by base64 decoding the payload member of the envelope. A DSSE signature covers the pre-authentication encoding of payloadType and these bytes.

Content root:

SHA-256 over the payload bytes. Other digests commit to the byte strings identified by their respective fields.

Approval record:

The record of one human act that approves one action ().

Relying party:

The component that lets an action run because of a decision.

Consumption record:

The durable record in which a relying party notes each approval it has honoured.

Mapping the Three Cases onto AUDIT Records All decision receipts here use the decisionType preActionAuthorization and carry validity with audience, nonce and expiresAt. A decision receipt is the gate's signed view of an event; the human act itself is the approval record, bound by digest. In the tables, IR stands for Interaction Record, ATR for Authorization Transition Record and AR for Action Record, followed by a placeholder field of the architecture. The fields common to all cases map as follows.

event_id

decisionId (outcomeId in an outcome receipt)

trace_id, parent_id

traceContext.traceId, traceContext.parentId

timestamp

decidedAt (performedAt in an outcome receipt)

actor, on_behalf_of

agent.id, principal.id

action

proposedAction (actionType, target, method)

exact action bytes

proposedAction.parametersDigest

authorization.expires_at

validity.expiresAt

delegation_chain

none (delegationRefs is not used here)

record signer

decisionMaker.id, bound to the key by a trust policy

Case 1, a Human Approval A gate asks a person before an action and records the answer. An earlier receipt for the same request, such as one with the verdict ESCALATE, is a separate record; this receipt does not reference it. After the answer the gate decides ALLOW for exactly the approved action. The approval record carries approvalId, approver, session, actionDigest (SHA-256 of the approved action bytes), approvedAt and validUntil. The decision receipt names it in inputSnapshot under the name "approval record". Case 1

Record, field	Decision receipt
IR, approval	approval record, by its digest in inputSnapshot
IR, actor	approver in the approval record, equal to principal.id
ATR, previous_state	not recorded in this receipt; preceding state must be established separately
ATR, new_state	verdict ALLOW for parametersDigest
ATR, trigger	reasonCodes contains user_approval
ATR, actor	approver in the approval record

The scope of the new state is one action, identified by its bytes. A second action, even one with the same name and target, needs a new approval.

Case 2, a Declined Action A gate declines an action because a rule or a person says no. The receipt records the verdict DENY with its reasons. It may say in actionOutcome that the call was blocked, which is the decision maker's own statement. Case 2

Record, field	Decision receipt
IR, refusal	verdict DENY or REFUSE
reason	reasonCodes
action	proposedAction with parametersDigest
no effect	actionOutcome.status blocked (self-asserted); no outcome with status executed names this decision in the supplied set
ATR	none; the state is unchanged

A receipt cannot prove that something did not happen. An observer at the boundary can separately report that it observed no effect. The check in detects a conflicting executed outcome in the supplied set; it does not establish absence of an effect.

Case 3, an Executed Action and Its Result A gate allows an action, the action runs, and an executor or an observer at the boundary records what happened in an outcome receipt signed with its own key. The outcome receipt names the decision by its content root in decisionRef. Case 3

Record, field	Outcome and decision receipt
AR, event_id	outcomeId
AR, parent_id	traceContext.parentId of the referenced decision
decision binding	decisionRef, the content root of the decision
AR, timestamp	performedAt
AR, actor	executor.id
AR, action	requestedActionDigest, equal to parametersDigest
result	status executed, effectDigest
authorization	the decision (ALLOW, validity.expiresAt)
evidence	evidenceRefs of the decision

The architecture asks that Action Records be produced at the boundary where the action took effect. Its WI-1-3 distinguishes the Recorder's signing identity from the recorded Agent's identity where they are operationally separate. checks that the outcome and decision use different keys and that executor.id differs from decisionMaker.id. Those checks alone do not establish operational separation or that the outcome signer observed the boundary.

What the Receipt Adds

• Exact bytes. The payload is its own serialization under . A verifier uses the received payload bytes for the signature input and content root. Canonical serialization is used to check equality and to derive the predicate's subject digest, never to repair or replace the received payload.
• A signature. Ed25519 over the DSSE pre-authentication encoding of the payload type and the payload bytes.
• Binding by digest. The action bytes (parametersDigest), the approval record and other inputs (inputSnapshot), the policy (policyBoundary.policyDigest), evidence (evidenceRefs), the decision itself (decisionRef in the outcome) and the observed effect (effectDigest) are named by SHA-256.
• Stated limits. The member notChecked lists what the decision maker did not check, and decisionChangeConditions lists what would change the decision.

What the Receipt Does Not Do

• It does not show that a decision was correct, safe or lawful.
• It does not authenticate the approval. The approval record in this document is not signed by the person it names. A deployment can additionally cite a separately signed approval in inputSnapshot. Validating that signature and establishing its correspondence to the approval record require rules beyond this document. The signed approvals of are one possible source of such evidence.
• It does not show that an effect happened. An outcome receipt shows that its signer stated an effect with a given digest. A digest that cannot be resolved to bytes shows only that a value was written.
• It does not register anything. Transparency in the sense of needs a separate registration and a SCITT Receipt.
• It does not detect a receipt that was never written, unless an observer or a sequence counter is added.
• Its times are the signer's clock.
• It is not an access token. A verified ALLOW is a record of a decision, and the executing system makes its own authorization check.

Evaluation Receipts Are Evidence, Never Authorization A decision may rest on an evaluation result, such as a test suite that passed. A Signed Evaluation Receipt records such a result. It appears in a decision receipt only as an entry of evidenceRefs whose digest is the receipt digest, SHA-256 over its payload bytes, as in . A verifier MUST NOT treat a valid Signed Evaluation Receipt, or its presence in evidenceRefs, as permission for an action. In the records of this document only a decision receipt with the verdict ALLOW, from a key the relying party trusts for decisions, records a permission.

Offline Verification The procedure below needs no network access. Each step either passes or ends the procedure with a failure named by the step. A later step never repairs an earlier failure.

Inputs The verifier needs the envelope bytes of each receipt and the Ed25519 public keys selected by its trust policy for the decision signer and, for Case 3, the outcome signer. It also needs the expected decisionMaker.id and, for Case 3, the expected executor.id whose assertion that policy permits under the outcome-signing key. An outcome signer may be an observer rather than the executor. The verifier supplies an evaluation time T in UTC; it does not take T from a receipt. Expected audience and nonce and the action and effect byte strings are optional inputs. Case 1 requires the approval record bytes. Inputs or evidence whose bytes are not checked remain digest references, not verified contents.

Decision Receipt

1. Envelope. Parse the envelope as a JSON object with the members payload, payloadType and signatures. payloadType MUST be application/vnd.in-toto+json.
2. Payload bytes. Decode payload as base64 into the payload bytes P.
3. Signature. Form PAE = "DSSEv1" SP LEN(type) SP type SP LEN(P) SP P, where SP is one space, LEN is the length in bytes as ASCII decimal without leading zeros, and type is the payloadType. At least one entry of signatures MUST carry a base64 sig that verifies as an Ed25519 signature over PAE under the expected key. The keyid member is not used to select a key.
4. Canonical form. P MUST be valid UTF-8 and parse as one JSON value with no duplicate member names. The serialization of the parsed value under MUST be byte for byte equal to P. A verifier MUST NOT continue with a re-serialized form.
5. Content root. Compute R = SHA-256(P).
6. Statement. _type MUST be https://in-toto.io/Statement/v1 and predicateType the decision receipt type of . subject MUST have one entry whose digest.sha256 is SHA-256 over the serialization of predicate.
7. Members. predicate MUST be a JSON object satisfying the field constraints of the strict v0.1 form in . It MUST contain schemaVersion, decisionId, decisionType, decidedAt, decisionMaker, agent, principal, proposedAction, inputSnapshot, policyBoundary (with policyDigest), evidenceRefs, decision, notChecked, decisionChangeConditions, privacy and validity. Other predicate members are limited to recordedAt, delegationRefs, actionOutcome and traceContext.decisionMaker, agent, principal, proposedAction, policyBoundary, decision, privacy and validity MUST be objects. decisionId, decisionMaker.id, agent.id and principal.id MUST be non-empty strings. inputSnapshot, evidenceRefs, notChecked and decisionChangeConditions MUST be arrays. decision.reasonCodes MUST be a non-empty array of non-empty strings.schemaVersion MUST consist of "0.1." followed by one or more ASCII decimal digits. decisionType MUST be preActionAuthorization. Every timestamp, when non-null, MUST be an UTC timestamp with a trailing "Z". Every non-null digest MUST be an object with exactly one member, sha256, whose value is 64 lowercase hexadecimal digits. A null is allowed only where the applicable field rules or explicitly permit it.
8. Signer. decisionMaker.id MUST be the identifier the trust policy binds to the key of step 3.
9. Validity. validity MUST carry a non-empty array of non-empty audience strings, a non-empty nonce string and an expiresAt timestamp. decidedAt MUST NOT be later than T, and T MUST be strictly earlier than expiresAt. Where an expected audience is given, audience MUST contain it; where an expected nonce is given, nonce MUST equal it.
10. Action bytes. Where the action bytes are given, their SHA-256 MUST equal proposedAction.parametersDigest.sha256.

Checks per Case

Case 1, approval.

decision.verdict MUST be ALLOW and decision.reasonCodes MUST contain user_approval. inputSnapshot MUST contain exactly one entry named "approval record". The approval record bytes A MUST be supplied, MUST hash to that entry's digest, and MUST be their own serialization.A MUST be a JSON object containing approvalId, approver, session, actionDigest, approvedAt and validUntil. approvalId, approver and session MUST be non-empty strings. actionDigest MUST have the digest form of and MUST equal proposedAction.parametersDigest. approver MUST equal principal.id. approvedAt and validUntil MUST be UTC timestamps with a trailing "Z". The bounds approvedAt <= decidedAt <= T < validity.expiresAt <= validUntil MUST hold.

Case 2, declined.

decision.verdict MUST be DENY or REFUSE. Where actionOutcome is present, its status MUST be notAttempted, blocked or refused, and performedAt and outcomeRef MUST be absent or null.

Case 3, executed.

decision.verdict MUST be ALLOW. The outcome receipt MUST have status executed and MUST pass against this decision.

Outcome Receipt

1. Apply steps 1 to 5 of separately to the outcome envelope with the expected outcome-signing key, obtaining payload bytes Q. Retain the decision receipt's content root R for the binding check below.
2. _type MUST be https://in-toto.io/Statement/v1 and predicateType the outcome receipt type, with a subject derived from predicate as in step 6 of .
3. Members. predicate MUST be a JSON object satisfying the field constraints of . It MUST contain schemaVersion, outcomeId, decisionRef, executor, requestedActionDigest, status and performedAt. Other predicate members are limited to effectDigest, actualActionDigest, responseDigest, policyPurpose, receiverRefs, sequence, recordedAt, limitations, traceContext and validity.schemaVersion MUST consist of "0.1." followed by one or more ASCII decimal digits. outcomeId MUST be a non-empty string. executor MUST be an object with a non-empty id string. status MUST be executed, refused, failed or partial. Each non-null timestamp MUST be an UTC timestamp with a trailing "Z". Each non-null digest MUST be an object with exactly one member, sha256, whose value is 64 lowercase hexadecimal digits. A null is allowed only where the applicable field rules permit it.
4. Binding. decisionRef.sha256 MUST equal the content root R of the decision receipt that passed , and requestedActionDigest MUST equal its parametersDigest.
5. Identity and separation. executor.id MUST equal the expected executor identifier supplied under . The verifier's trust policy MUST permit the outcome-signing key to attest that identifier. That key MUST differ from the decision maker's key, and executor.id MUST differ from decisionMaker.id. These checks do not establish that the two keys are controlled by operationally independent parties.
6. Result. status executed MUST come with a non-null effectDigest. Where effect bytes are supplied, effectDigest MUST be present and their SHA-256 MUST equal effectDigest.sha256.
7. Time. performedAt MUST NOT be earlier than the decision's decidedAt and MUST be strictly earlier than its validity.expiresAt.

Checks over a Set of Receipts An Auditor that holds the receipts and approval records of a run can check two properties that no single receipt shows. The Auditor MUST obtain the relying party's consumption scope from its audit context or trust policy; that scope is not inferred from an approvalId alone. First, within that scope, no two distinct ALLOW decision payloads, identified by different content roots, may cite approval records with the same identity (approvalId, actionDigest and session). Such a pair violates ; additional copies or signatures of one payload do not. Second, no outcome receipt with status executed may name, in decisionRef, the content root of a receipt with the verdict DENY or REFUSE. Both checks are only as complete as the set of receipts the Auditor holds. The first check does not detect two executions that reuse one ALLOW receipt without producing another decision receipt.

What a Pass Shows A pass shows that the holder of the decision maker's key signed exactly these payload bytes, that they name the action, approval, inputs and evidence by the digests checked, and, for Case 3, that the holder of a different key, which the trust policy permits to attest the expected executor.id, signed an outcome with status executed bound to that decision. It does not show that the signer's statements are true, that the approval came from the named person, that the outcome signer observed the boundary, that no other receipt exists, or that the keys were not misused. Those questions belong to the trust policy, to signed approvals, to observers and to transparency registration.

Approvals Are Honoured At Most Once An approval in Case 1 frees one action once. For live use, the relying party MUST apply the time bounds of with its own current time as T. A historical audit time MUST NOT make an expired approval usable. A relying party that lets an action run because of an approval:

1. MUST honour each approval at most once;
2. MUST key its consumption state by the identity of the approval (approvalId, actionDigest and session), not by the bytes of one copy of the approval record. Copies or reissues with other metadata count as the same approval and MUST NOT extend its original validUntil. Extending that validity requires a new approval act and a new approvalId;
3. MUST mark the approval as consumed durably before it either allows the action to run or releases a signed ALLOW that cites the approval;
4. MUST treat an approval recorded as consumed in any current, rotated, archived or compacted representation as consumed for as long as item 6 requires that state to be retained;
5. MUST NOT honour an approval unless it can consult a complete, durable view of the consumption state required by this section. Rotation, archiving or compaction MAY replace earlier generations if all entries still required by item 6 are preserved. Missing or unreadable state whose required entries have not been preserved elsewhere MUST cause refusal;
6. MAY drop an entry only after the approval's original validUntil, plus the clock skew it allows, has passed and no copy of that approval can still be honoured.

Rotation is the step where this requirement is most easily lost. A record that is full is moved aside so that new approvals can be written; if the relying party then reads only the new generation, approvals of the old one may become usable again. Items 4 and 5 preserve the consumed state without requiring a particular storage format. A decision receipt for Case 1 binds the approval record by digest, so can expose distinct ALLOW decisions for the same approval identity. Preventing reuse of an approval or of an already issued ALLOW remains the relying party's duty.

Implementation Status This section is given per and is to be removed by the RFC Editor before publication. proofbundle 6.4.0 is on PyPI with the classifier "Development Status :: 4 - Beta"; its tag v6.4.0 is commit 699545521ec5ef479bb84e61fe7461fc79ed558c of . There the decision receipt predicate is described as shipped since version 2.1.0 and the outcome predicate as experimental. In the seven command line runs reported in , the four passing vectors returned exit code 0, the invalid signature of V1-bad returned 1, and the non-canonical payload of V2-bad and the decision binding mismatch of V3-bad each returned 2. These results do not specify the command line interface's complete exit-code contract. Agent Guard is the name used here for the preview in plugins/proofbundle of the same repository, inspected at commit 8bb289c8b41d32c54734155fc00756231093bc2a. This inspected revision is not the release tag v6.4.0. Its public README names the preview the proofbundle plugin for Claude Code and Codex. In the inspected code, the configured receipt pilot uses a separate signing service for preActionAuthorization decisions with verdict ALLOW, DENY or ESCALATE for the writes it supports. An observer signs outcome receipts for effects it matches to decisions. The runbook assigns the observer to an operator account separate from the agent session. The approval path requires an explicit operator configuration and is not enabled under Codex. It binds an approval to the command bytes and its session. Its time check accepts the approval from 60 seconds before the recorded answer, to allow for clock skew, through 15 minutes after it. For a write covered by the receipt pilot, the hook obtains a signed ALLOW before recording its own use of the approval and allowing the command. These are observations of the source and runbook, not a live Agent Guard execution measured for this document. The test vectors of were produced with proofbundle 6.4.0 from PyPI and test keys, not by Agent Guard. For an approval, the inspected pilot writes released_by_owner among its reason codes where the vectors write user_approval. It does not put the approval record's digest into inputSnapshot, may add the digest of configured closing rules there, sets no traceContext or actionOutcome, and leaves evidenceRefs empty. The vectors therefore do not demonstrate that the preview produces Case 1 receipts conforming to this document. At the inspected commit, the signing service keeps its record of honoured approvals without eviction and refuses a new approval when the record holds 4096. The runbook has an operator rotate a full record, with the service stopped, by copying it into the folder honoured-releases of the records and then removing it. The service treats an approval named in the current record or in any file of that folder as honoured, before its decision and again under its lock before it releases the signature. If that folder or a file in it is a symbolic link, is owned by an account other than root or the service's own, or is writable by another account, or if a file there does not read as a record, the service releases no signature in the configuration in which it honours approvals. The hook keeps its own record of the approvals it has used, keyed by an identity that excludes the answer time, and treats a copy of a used approval as used whatever answer time it carries. When the record holds 1024 uses, the hook removes only uses recorded more than 15 minutes and 60 seconds earlier, after which the copy that was used is no longer within its window, and keeps a digest of each removed identity, which it does not remove; a copy of such an identity is refused. If the record is still full, would exceed 512 KiB, contains a field the hook does not know, or cannot be read or written, the hook does not honour the approval. In both layers the validity window is taken from the answer time of the copy in use, and neither keeps an original validity per identity. For an identity that has not yet been used, a copy with a later answer time therefore opens a later window; item 2 of does not permit that. At the earlier commit ba8466d1a04334a5d83b3eaa12e30a464cc9d686, the signing service did not read archived records and the hook removed its oldest use without checking that entry's age; both were gaps relative to . No conformance of Agent Guard to and no enforcement of single use in a running host is claimed from these source-level observations. The separate Go checker supplied with the vectors and the proofbundle 6.4.0 command line interface agree on acceptance or rejection of all seven vectors. This comparison does not establish complete equivalence of the verifiers, conformance of Agent Guard to Sections 3 and 4, or enforcement of single use in a running host. No later implementation revision is assessed here. This information is given per and does not constitute endorsement.

Relation to Other Work defines one in-toto predicate type, signed in DSSE with canonical bytes, that carries an authorization decision and the observed effect together with a derived agreement between them, and offers it as a data model for AUDIT records. This document keeps decision and outcome in two receipts signed under different keys and maps three cases onto the architecture; the consumption-state input that names concerns the same kind of state as . specifies permissions that a principal signs with a passkey and action receipts signed by the agent, linked to earlier receipts and appended to a log by a recorder. It also defines a passkey-signed approval of one action. Such an approval could supply additional evidence for Case 1. Citing it by digest does not replace the approval record or the checks of ; this document defines no mapping from that format to the approval record. defines a verdict record that states a result on a claim and cites its evidence by digest, in any receipt format. A decision or outcome receipt of this document can be such evidence, and a verdict record can state the result of the procedure of . defines a data format for agent conversation records protected by COSE signatures, which names as a candidate for Interaction Records. A signed conversation record can be cited by digest as additional input. Establishing which entry records a human approval and how it corresponds to the action, approver, session and validity of Case 1 requires a mapping not defined here. The approval record and the checks of still apply. SCITT makes the existence of a signed statement undeniable through registration and Receipts. A decision or outcome receipt can be registered as the payload of a Signed Statement, or by its content root, which adds what says the receipt lacks.

Security Considerations Key binding. A receipt is only as trustworthy as the verifier's choice of keys and its policy for the identities those keys may attest. checks decisionMaker.id; checks the expected executor.id under the outcome-signing key. An observer's signature over an executor identifier is not the executor's own signature. A key held in the recorded Agent's process gives an Auditor that does not trust that Agent little assurance. The inspected Agent Guard design uses separate service accounts as described in . Exact bytes. A verifier that re-serializes a payload before checking it can be led to accept bytes that were never signed, or to compute another content root. Step 4 refuses such payloads, and vector V2-bad tests it. Replay. An ALLOW for one action must not free another, and an outcome that names another decision must not count as the result of this one. parametersDigest binds the action bytes, validity binds audience, nonce and expiry, decisionRef binds the outcome, and requires the relying party to prevent reuse of an approval. V1-bad tests rejection of changed payload bytes under an unchanged signature. V3-bad tests rejection of an outcome bound to a different decision. The seven vectors do not test consumption-state retention or rotation. Self-assertion. actionOutcome in a decision receipt and an outcome receipt whose effect cannot be resolved are statements of their signers. A digest that is present but cannot be resolved to bytes was chosen by the signer. Suppression. A decision maker can fail to write a receipt for a decision it does not want seen. Independent observers at the boundary, as the architecture requires for Action Records, and registration with a Transparency Service reduce this risk; this document does not remove it. Clocks. decidedAt and performedAt come from the signers' clocks. Ordering against outside events needs a timestamp or a transparency registration.

Privacy Considerations The receipts of this document carry digests of action bytes, approval records and effects instead of their content, and state rawInputsIncluded false. A digest of a short or predictable input, such as a command line, can be found by trying candidate inputs; a deployment that must hide such inputs keeps the receipts as private as the inputs, or adds a secret salt to the digested bytes. Identifiers such as principal.id, agent.id and traceContext link a person's actions across services, as Section 9 of describes; pairwise or opaque identifiers reduce that linkage. Registering a receipt reveals that a decision took place at a time, even when only its content root is registered.

IANA Considerations This document has no IANA actions.

References Normative References Secure Systems Lab in-toto project proofbundle project proofbundle, tag v6.4.0, docs/predicates/decision-receipt.md proofbundle project proofbundle, tag v6.4.0, docs/predicates/action-outcome.md Informative References Python Package Index proofbundle project

Test Vectors The vectors were generated with proofbundle 6.4.0 from PyPI and are for testing only. Each key seed is SHA-256 over a public ASCII label, so that every byte can be rebuilt; these keys MUST NOT be used for any real receipt. Ed25519 is deterministic, so the signatures below follow from the seeds and the payloads.

Test Keys and Inputs Each key is given by its label, Ed25519 seed (hex), public key (base64) and keyid. The key labelled gate-1 signs the decision receipts; the key labelled observer-1 signs the outcome receipts. For these tests, the trust policy accepts decisionMaker.id gate-1 under the gate-1 key and permits the observer-1 key to attest executor.id forge:agent-42-bot. The key label observer-1 does not assert that the observer is the executing account. Each input is given by a name, its bytes, its size and its SHA-256. "\n" stands for one line feed byte. The bytes of ap, a3 and e3 are the serialization under of the JSON value shown, on one line and without white space. In ap, SHA-256(a1) stands for the JSON string of the 64 lowercase hexadecimal digits of the SHA-256 of a1. pol is the policy named by every policyDigest. B is the payload of vector P1 of , Appendix A.2.1, cited by V3-decision.

Statements The payload bytes of each vector are the serialization under of a Statement {"_type": "https://in-toto.io/Statement/v1", "predicateType": P, "predicate": D, "subject": [{"name": N, "digest": {"sha256": H}}]}, where H is SHA-256 over the serialization of D. For a decision receipt P is the decision receipt type and N is "decision:" followed by decisionId; for an outcome receipt P is the outcome receipt type and N is "outcome:" followed by outcomeId. Each predicate is given as a list of assignments that starts from the predicate named in its first line, {} being the empty object. An assignment sets the member at the path to the JSON value shown. A path is a sequence of member names joined by dots, where a decimal index i in square brackets after a name selects element i of an array; missing objects on the path are created, and an assignment to element i of an array with i elements appends it. Members not named keep their value. SHA-256(x) stands for the JSON string of the 64 lowercase hexadecimal digits of the SHA-256 of input x, and R(V) for that of the payload bytes of vector V. V1-bad has the payload bytes of V1-good with every occurrence of the hexadecimal SHA-256 of a1 replaced by that of a1x, and keeps the signature of V1-good. V2-bad has as payload bytes the output of Python's json.dumps(s, sort_keys=True) for the Statement s of V2-good, with a space after each comma and colon, and is validly signed over them by gate-1.

Results Every envelope is {"payload": base64 of the payload bytes, "payloadType": "application/vnd.in-toto+json", "signatures": [{"keyid": keyid of the signer, "sig": signature}]}. Each block below gives the vector, the evaluation time T, the expected result with the exit code of the proofbundle 6.4.0 command line interface, the payload size and signer, the SHA-256 of the payload bytes (the content root where the payload is canonical) and the signature in base64 on two lines. The expected audience is observer-1 and the expected nonce is the decisionId. decision verify ran with --strict, --aud, --nonce and --verification-time T; outcome verify with --strict, --expected-decision-ref R(V3-decision) and --decision-maker-id gate-1. The payload bytes of V1-good, V2-good, V3-decision, V3-good and V3-bad and the inputs ap, a3, e3 and B are each equal to three serializations of their parsed value: Python's json.dumps with sort_keys=True, separators=(",", ":") and either setting of ensure_ascii; the rfc8785 package 0.1.4 for Python; and the independent JavaScript implementation . The values contain no floating-point numbers and no characters outside ASCII, which keeps these serializations equal. The payload of V2-bad differs from all of them, as intended.

Acknowledgments The author used AI tools to help draft this document and to generate and cross-check its examples. The author reviewed the entire text and is responsible for it. Citing adjacent work in the References does not imply that its authors endorse this document.