]> Action State Group, Inc.

spec@actionstate.ai

Security agent attestation bilateral cross-organization SCITT transparency refusal When an agent operated by one organization requests a consequential action from an agent operated by another, today's record of that exchange — if one exists — is kept by one side, editable by that side, and deniable by the other. Disputes reduce to my-log-versus-your-log. This document describes a bilateral attestation exchange for such actions: the requesting organization signs a request attestation binding it to the action and its material terms; the performing organization evaluates the request against deterministic constraints at the boundary where the action takes effect and signs an action attestation recording the constraint results and the disposition — performed, declined, or escalated to a human — by reference to the request; and each party acknowledges the other's attestation. The combined record binds each organization to its part, gives each proof of the other's, and can be anchored to a transparency service so that a third party who trusts neither organization can verify its integrity, timing, and both parties' signatures. The exchange records refusals with the same fidelity as performance, and degrades gracefully when a counterparty cannot attest, marking the record's reduced assurance rather than blocking the transaction.

Introduction Agents increasingly transact with agents of other organizations with no human present at the moment of delegation. The transports are standardized — RPC conventions, tool-call protocols, message queues — but transports answer how agents communicate, not who is accountable for what was requested and what was done. Each side keeps its own log, written by an interested party, alterable by that party, and carrying no assent from the other. When the payment posts twice, when the deletion was out of scope, when the delivery never happened, the evidence is two self-interested logs that need not agree. Classical signed B2B messaging — AS2/EDIINT signed MDNs, AS4/ebMS3 signed receipts with non-repudiation-of-receipt — binds parties to transmissions: it attests that a message was sent and received, not what an agent then did about it. Such schemes do not gate execution on verifying the requester's organizational identity at the boundary where the action takes effect, do not bind constraint evaluation into the performer's record, and do not record a disposition distinguishing an executed action from a refusal from a human escalation at the moment of action. The distinction this document draws is action-level, not transport-level. This document describes an exchange producing a bilaterally attested action record: each organization's signature over its part of the exchange is durable, independently verifiable evidence that it produced that part, each holds proof of the other's, and the combined record can be anchored so third parties can verify it. It is an individual submission. It composes with the existing agent action record layer rather than defining a new one, and its records are designed to be consumable by the layers above the record, such as accountability composition .

Motivating Scenarios Cross-organization procurement. Org A's purchasing agent requests a fulfillment action from org B's agent. A's request attestation binds A to the order's material terms; B's action attestation binds B to what it did about them. A later assertion of different terms by either party can be checked against a record both parties signed, rather than argued over two private ones. Agent-to-agent service delegation. An orchestrating agent subcontracts a task across a trust boundary. Each hop produces its own bilateral record, so a failure in a multi-hop chain is attributable to the hop where it occurred rather than to the chain as a whole. Chain-linking semantics that make the full responsibility path independently reconstructable are left to a future revision. Refusal at the boundary. B's agent declines A's request as out of policy. B's action attestation records the decline and its constraint basis; A's acknowledgment is verifiable evidence contradicting a later claim by A that the request was never answered. The refusal becomes durable, third-party-verifiable evidence — for B, that its gate worked; for A, that the request was made and declined (see ). Feeding shared history. Every completed handshake yields a counterparty-attested record — the highest-assurance evidence class for any layer that computes over action history. Two organizations that transact build verifiable shared history as a side effect of transacting.

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.

Requesting party:

The organization (via its agent) requesting a consequential action across an organizational boundary.

Performing party:

The organization (via its agent) that evaluates and disposes of the requested action.

Request attestation:

A signed statement by the requesting party describing the requested action and its material terms, bound to the requesting party's verifiable organizational identity and naming the intended performing party; including at minimum a content digest of the request, a nonce, a timestamp, and a validity window. A request attestation is valid only against the performing party it names, and only within its validity window (with an implementation-defined clock-skew tolerance the verifier applies).

Action attestation:

A signed statement by the performing party, referencing a request attestation by digest, recording the deterministic constraint results evaluated at the effect boundary — each constraint identified by reference so a third party can tell which check produced which result — and the disposition of the request, bound to the performing party's verifiable organizational identity.

Acknowledgment:

A signed statement by which a party records receipt of the counterparty's attestation, completing the bilateral record. Receipt does not assert agreement with the attestation's contents; a party disputing a disposition does so in a subsequent linked record.

Verifiable organizational identity:

An organizational identity a relying party can validate independently of that organization's infrastructure — a credential chaining to a root of trust the relying party accepts (a certificate authority, federation operator, registry, or published trust list). This document does not nominate roots.

Reduced-assurance indicator:

A marker recording that a given exchange completed with fewer than the full set of attestations (see ).

The Bilateral Exchange The exchange has four moves: Request attestation. Before the performing party acts, the requesting party produces a request attestation over the action and its material terms. The requester is now bound: it cannot later deny having asked, or having asked on these terms. Constraint evaluation. The performing party verifies the requester's organizational identity and evaluates the request against deterministic constraints at the boundary where the action would take effect — not at the transport edge. Verification gates execution: no verified request attestation, no consequential action (policy MAY permit degraded operation; see ). Action attestation. The performing party produces an action attestation referencing the request attestation by digest and recording the constraint results and the disposition. Dispositions use the verdict-complete vocabulary of verbatim — executed, blocked, denied, timeout, errored, deferred, expired, escalated — so the record covers every outcome, not only success. A performing party MUST produce at most one action attestation per request attestation; repeated execution of a single request is representable only as distinct request instances, each with its own request attestation. Acknowledgment. Each party acknowledges the other's attestation. On completion, each organization is bound to its part and holds proof of the other's. Attestations and acknowledgments SHOULD be anchored: registered to a transparency service per — carried, for example, as the payload of a profiled Signed Statement per — so that inclusion and non-equivocation are verifiable by a party who trusts neither organization. An unanchored bilateral record still binds the two parties to each other; anchoring is what makes it evidence for everyone else. Wire encodings for the four objects are TBD for a future revision; this document fixes the exchange, the binding obligations, and the disposition semantics.

Refusal Across the Boundary A declined request is not a failed exchange; it is a completed exchange with a decline disposition. The action attestation records that the request was declined and on what constraint basis; the requester's acknowledgment completes the record. This has two consequences. For the performing party, a bilaterally-acknowledged decline is evidence, verifiable by an auditor who trusts neither party, that its boundary enforcement works — the strongest form of refusal-as-positive-signal evidence, because here even the counterparty that was refused has signed the record. For the requesting party, a history of acknowledged declines is legible too: a pattern of out-of-policy requests is now provable by its counterparties. Bilateral records cut both ways by construction; parties should expect their requesting behavior, not only their performing behavior, to become reputation-bearing.

Graceful Degradation Counterparties will be of mixed capability for years. A performing party whose counterpart cannot produce request attestations MAY proceed under policy, producing its own action attestation unilaterally and recording a reduced-assurance indicator in place of the missing attestations. The record format is the same; the assurance marking differs. This keeps one protocol across mixed peers while preserving the distinction relying parties need: a fully-bilateral record and a degraded record are never confusable, and consumers can require a minimum assurance level. Degradation MUST be recorded, never silent.

Relationship to Existing Work Record layer. This document defines an exchange, not a record format: its attestations are designed to be carried in existing agent action records — the Agent Action Capsule supplies the disposition vocabulary, effect binding, and anchoring path this document relies on, and its selective-disclosure profile applies to cross-boundary privacy (). Delegation receipts. binds a principal (the delegating user) to an authorization before any action, on one side of the boundary. This document binds two organizations to a specific action at the moment of action. The two compose: a request attestation may reference the delegation receipt authorizing the requesting agent. Remote attestation. RATS attests platform and workload state — what software is running where. This document attests actions — what was requested and what was done. A deployment may use RATS evidence to strengthen confidence in a counterparty's agent runtime; the two are orthogonal layers. Audit and approval records. The audit architecture describes recording agent interactions across parties, and records human authorization of high-risk actions; both are complementary record sources this exchange can feed and reference. The accountability composition describes how such records compose by shared action digest; a bilateral record naturally fills its cross-party leg.

Security Considerations Identity is the floor. The evidentiary weight of a bilateral record is bounded by the binding of keys to organizations. This document inherits, and does not solve, the organizational-identity problem; it requires only that the credential chain to a root the relying party accepts, and that identity be bound to the record, not merely the transport session. Half-completed exchanges. A party that aborts mid-exchange (requests, then never acknowledges the decline; performs, then withholds the action attestation) creates an asymmetric record. Timeout dispositions and anchoring deadlines bound the asymmetry: an unacknowledged attestation anchored with a timeout marking is itself evidence of the counterparty's non-completion. Policies SHOULD treat chronic non-completion as reputation-bearing. Downgrade attacks. If degraded operation is permitted, an attacker prefers to be recorded at reduced assurance. Reduced-assurance records MUST be unambiguously marked, acceptance of degraded exchanges is a policy decision of the performing party, and consumers SHOULD weight degraded records accordingly. Silent downgrade is the failure mode to design out. Replay and cross-binding. Nonces and digests bind each attestation to one request instance; an action attestation MUST NOT be verifiable against any request other than the one it references. Key compromise and revocation. A signature valid at attestation time may be produced under a key compromised by verification time. A verifier SHOULD be able to establish key validity as of the attestation's anchored time, not only at verification time; revocation and rotation semantics for organizational keys are inherited from the identity layer and are out of scope here, but a record without an anchored time cannot support this distinction. Canonicalization and hash agility. Because every binding is by digest, the canonicalization of the attested objects is security-relevant: divergent serializations of the "same" terms produce different digests, and ambiguous canonicalization enables terms-substitution disputes. A future revision fixing wire encodings MUST specify a deterministic canonicalization (e.g. JCS, ) and carry an explicit hash-algorithm identifier for agility. Verification-cost DoS. Verifying a request attestation (identity-chain plus anchor inclusion) is more expensive than producing one. A performing party SHOULD be able to cheaply reject unverifiable request attestations before performing full verification, so request-attestation flooding cannot exhaust a performer at the effect boundary.

Privacy Considerations A bilateral record discloses, by construction, that two organizations transacted — to each other, and if anchored with cleartext identifiers, to anyone. Deployments SHOULD anchor commitments rather than cleartext (selective-disclosure structures per ), disclose material terms only to the counterparty and auditors, and treat counterparty identity itself as a selectively-disclosable field where the use case allows. Correlation of anchored records across a party's exchanges (client-list reconstruction) is the residual risk; mitigations are TBD alongside the reputation layer's, which faces the same problem from the consumption side.

IANA Considerations This document has no IANA actions at this time. A future revision defining wire encodings is expected to register media types for the four exchange objects and a registry for reduced-assurance indicator values. TBD.

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. 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 expressed as SCITT Signed Statements (COSE_Sign1) and made transparent by registration in a SCITT Transparency Service. A Capsule is recorded on every verdict, including refusals: a blocked or denied Capsule is the auditor-grade evidence that a gate worked. 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. 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. Action State Group, Inc. MyAuberge K.K. Independent EMILIA Protocol, Inc. Autonomous and semi-autonomous software agents increasingly take consequential actions across administrative and trust domains. Holding such an action accountable — to a regulator, auditor, or counterparty who does not trust the operator — requires answering several questions, each answerable by an independently-verifiable profile: whether the agent was permitted to act (CAN), which accountable human authorized the specific action (WHO), what the agent actually did (WHAT), and whether the runtime enforced correctly (AUDIT). This document specifies, in Informational terms, how such profiles compose — by a shared action-digest, each verifying independently — and defines a shared conformance-vector suite against which any profile may be tested. It complements existing audit-architecture and record-format work rather than replacing it, reusing existing signing, transport, and transparency mechanisms. Its focus is an assurance tier those documents leave open: most agent records today are self-attested by an interested party; this document makes reachable and testable an anchored, third-party-verifiable tier, in which a record is registered to a transparency service (SCITT) so a party who trusts neither the agent nor the operator can verify it. Self-attestation remains a valid baseline; convergence on the disinterested tier — by any conforming profile — is the goal, not a single mandated format. Action State Group, Inc. This document normatively profiles the per-field selective-disclosure extension point reserved in draft-mih-scitt-agent-action-capsule-01 Section 9.2 (Selective Disclosure). It defines the salted-hash commitment encoding, decoy-digest construction, disclosure format, producer requirements, and verifier checks for selectively disclosable fields in Agent Action Capsule payloads. The mechanism follows the SD-JWT selective-disclosure model (RFC 9901) — salted- hash commitments, decoy digests, and disclosed [salt, name, value] triples — using JCS (RFC 8785) canonicalization, which is already the base Capsule profile's canonical form. SD-JWT (RFC 9901) is the JSON form; SD-CWT (draft-ietf-spice-sd-cwt) is the CBOR/dCBOR sibling. Because the Capsule payload is JSON, this profile uses the SD-JWT (JSON) construction, cited alongside the SPICE WG's SD-CWT work for SCITT-ecosystem consistency. Verifier checks are deterministic and reproducible from the Capsule bytes plus a provided disclosure set alone; no clock, network access, model invocation, or external lookup beyond the provided disclosures is required. Authproof This document defines the Delegation Receipt Protocol (DRP), a cryptographic authorization primitive for AI agent deployments. Before any agent action executes, the authorizing user signs an Authorization Object containing scope boundaries, time window, operator instruction hash, and model state commitment. This signed receipt is published to an append-only log before the agent runtime receives control. The protocol reduces reliance on the operator as a trusted intermediary by making the user's private key the sole signing authority over the delegation record. 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 additonal logging for transparency. EMILIA Protocol, Inc. This document defines the EMILIA Protocol (EP) authorization receipt, a cryptographic primitive that binds a named, accountable human approver to one exact high-risk action before that action executes. An approver holding their own signing key produces a signature over a canonical Authorization Context containing the action hash, policy reference, one-time nonce, and validity window. The resulting Trust Receipt is Merkle-anchored and verifiable fully offline: a relying party can confirm that a specific action was approved by an authorized human, exactly once, without network access to any EP operator, log, or API. The protocol additionally enforces separation of duties (an initiator must not approve its own action) and one-time consumption (an authorization, once consumed or refused, is terminally unusable). These invariants are machine-checked in published TLA+ and Alloy models. EP addresses organizational authorization of agent actions (approver- to-action trust). It is complementary to, not a replacement for, user-to-operator delegation work (draft-nelson-agent-delegation- receipts), service-to-service identity (WIMSE), and authentication- layer approval (CIBA). EP is the human-authorization apex of the agent stack: it composes with, and does not replace, the agent identity, delegation, machine-policy, and transparency-log layers, supplying the named-human authorization evidence those layers reference but do not themselves produce. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols.

Acknowledgments This exchange pattern owes its framing to discussions in the SCITT and agent-accountability communities, and composes with the work of the authors cited above.