]> Action State Group, Inc.

steven@actionstate.ai

MyAuberge K.K.

Japan tomsato@myauberge.jp

Independent

bluedognull@gmail.com

EMILIA Protocol, Inc.

team@emiliaprotocol.ai

Security agent accountability audit SCITT composition conformance attestation 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.

Introduction Autonomous agents are non-deterministic, act without per-step human oversight, cross administrative and trust boundaries, and delegate to other agents. The assumptions that let earlier systems be trusted — predictability, runtime supervision, a nameable human in the loop — do not hold by default. When behaviour cannot be supervised as it happens, trust must relocate to evidence that can be checked afterward and, because agents act across organizational boundaries, checked without trusting the operator. Identity and authorization are necessary but not sufficient: they establish which agent and what it was permitted to do, but the risks that characterize agent systems — goal drift, prompt injection, fabricated tool results, action outside scope — occur in the gap between what was authorized and what was actually done. Holding a consequential agent action accountable therefore 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 does not define a new audit architecture; it complements the existing architecture and record-format work in this space (see Relationship to Existing Work) and specifies the piece they leave open: how profiles answering these questions compose, by a shared action-digest, into one record, and how conformance — both to that composition and to an anchored, third-party-verifiable assurance tier — is tested. Two principles frame it: (1) composition by shared digest, not containment — each profile verifies independently and refers to the same action by a shared digest; and (2) producer-agnostic neutrality — no profile is a required root of trust for another. The set of questions is open and extensible (agent identity and belief-provenance are natural further slots), and the composed evidence serves both after-the-fact accountability and the forward-looking authorization and trust decisions that rely on it.

Terminology Slot; profile; composition vector; profile-tagged digest; trust root. [Define in a later revision; align with the constituent-profile terminology.]

Overview: Questions and Composition The work centers on a set of interchangeable slots, each a question that a conforming profile answers: CAN — the "may": was the agent permitted to act? WHO — which accountable human authorized this exact action? WHAT — the "did": what did the agent actually do (verdict-complete; a byte-stable serialization of the observed record, not a replay)? AUDIT — did the runtime enforce correctly, in causal order, tamper-evidently? Any conforming profile may fill a slot; the profiles cited in this document are the first instances, not the definition. An action fills the slots its trust requirement calls for; not every action populates every slot. The set is extensible (see Extension Points).

The Composition Model Profiles compose by reference to a shared subject digest over the action — subject_digest = SHA-256(JCS(action)) — which is the join key all slots refer to. A profile-tagged authority-reference digest binds a slot's evidence to the registered object it commits to, and a receipt-payload digest binds transparency receipts. Digests committing to signed bytes require deterministic encoding. Digest equality is a join key: it does not, by itself, prove truth, authorization, sufficiency, completeness, or policy compliance. Native profile verification, digest recomputation, receipt or transparency verification, completeness and sequencing checks, and relying-party acceptance remain separate results. [Full three-digest binding rules, profile-label discipline, and raw-bytes-vs-ASCII -hex rules to be imported from the digest-binding thread / conformance issue in a later revision.]

Trust-Root Separation Each slot may root in a different trust anchor (e.g. a human device key, a kernel attestation key (), a transparency-log operator). The composition holds even if any one party is compromised or under review. No slot is a required root of trust for another; profiles remain producer-agnostic.

Slot Profiles The profiles in this section are first instances filling the slots named above, recorded so the composition can be tested against something concrete. They are not the slot definitions; any conforming profile may fill a slot (see Overview). Each profile's text is contributed and maintained by its authors.

The CAN Slot [Profile text to be contributed by the slot's owners.]

The WHO Slot: Named-Human Authorization The WHO slot answers a single question: which named, accountable human — or quorum of distinct humans — authorized this exact action before it ran. It is deliberately narrow. It does not define the composition model itself, a sufficiency or policy decision, a new audit-record format, or a replacement for agent or workload identity: "which agent acted" is a different slot, and "was this authorization sufficient for this action" is a layer above the composition. It binds the authorization to the exact observed action by the composition's shared action digest — the subject digest of the Composition Model — and exposes the binding metadata a composition verifier needs, and nothing more. Digest equality itself neither authorizes the action nor proves completeness. In the first-instance profile (, with the receipt format in ), the WHO record is an authorization receipt: a device-bound signature by a named principal — or a set of distinct principals — over the canonical bytes of one action, verifiable offline against the signer's public key. Any record form meeting the producer and verifier requirements below conforms. A conforming WHO producer MUST state: the authorizing principal identifier(s) — the named human(s), not the agent; for a quorum, the quorum descriptor (an M-of-N threshold or an ordered sequence) and the eligible or actual signer identifiers; the subject of the action being authorized; the covered action bytes or data model, the canonicalization rule (if any), the digest algorithm and version, and the domain-separation context; the binding between the subject digest and the receipt signature(s) — the signed payload MUST cover the digest; the validity window and any freshness or one-time-use semantics; and the failure behavior when a required binding input, signer, or quorum member is absent — fail closed: absence of authorization is not authorization. A conforming WHO verifier MUST be able to produce a result that states: whether each signature validates under the profile rules; the exact digest bytes it recomputed and the canonicalization and hash parameters used; whether the digest is covered by each signature; for a quorum, whether the threshold is met, whether the counted signers are distinct principals, whether every counted signer signed the same canonical action bytes under the same digest context, and — for an ordered quorum — whether the required order held; whether the receipt is within its validity window and any one-time-use constraint; and the verified-versus-accepted distinction (below). The verifier MUST keep signature validation, digest recomputation, quorum evaluation, and freshness as separate results, and MUST NOT collapse them into a single opaque "authorized" boolean. The WHO slot separates two claims a composition verifier must never conflate: VERIFIED — the signature(s) and the digest binding hold, given a public key; objective and offline — and ACCEPTED — the relying party additionally trusts the authorizing principal(s) via out-of-band key pinning; a relying-party decision, not a property of the receipt. A WHO verifier MUST surface these separately: a valid signature over the bound digest proves VERIFIED and never implies ACCEPTED, and neither implies the authorization was sufficient for the action. At the composition join, the WHO slot exposes a minimal, disclosure-aware reference: the subject digest and its declared digest context; the authorizing principal identifier(s) — or, under selective disclosure, a commitment to them; the quorum descriptor, if any, with a distinctness assertion; and the binding assertion that the signature(s) cover the subject digest. The reference carries no agent identity, no policy verdict, and no sufficiency claim. Where a WHO record is also registered to a transparency service (see Assurance Tiers), the transparency receipt proves registration of the submitted statement under the service policy; it does not prove that a named human authorized the action. A WHO verifier MUST keep native signature validation, digest recomputation, and transparency-receipt validation as separate results. In addition to the composition-level negative classes (see Conformance), a WHO profile MUST reject each of the following, and the verifier MUST report which check failed: semantically similar action input with different canonical bytes; a changed subject; a changed authorizing-principal reference; replay of the receipt under a different action (a different subject digest); a quorum satisfied by a non-distinct principal filling two slots; an ordered quorum satisfied out of order; a threshold not met; a mismatched or absent receipt signature; a signature that verifies but whose signed payload does not cover the subject digest (an unbound signature); a stale receipt; a post-hoc ratification presented as pre-execution authorization; a reusable authorization presented under one-time semantics, or a one-time authorization presented as reusable; and WHO digest bytes that do not match an adjacent slot's digest for the same claimed action under compatible digest contexts (per the binding rules of the Composition Model, to be imported). [The WHO positive-vector classes are imported with the conformance suite in a later revision.]

The WHAT Slot [Profile text to be contributed by the slot's owners.]

The AUDIT Slot [Profile text to be contributed by the slot's owners.]

Assurance Tiers A record answering these questions may be produced at different assurance levels, and the distinction is the crux for a relying party who does not trust the operator: Self-attested (baseline). The record is signed by the agent or its operator and held by an interested party. This is useful telemetry and a reasonable default, but it cannot, by itself, satisfy a regulator, counterparty, or insurer who does not trust the producer. Anchored / third-party-verifiable. The record, or a digest of it, is registered to a transparency service — the SCITT substrate () — yielding a receipt that lets a party who trusts neither the agent nor the operator verify the record's existence, its content at registration time, and non-equivocation, independent of any single producer's infrastructure. This document does not mandate the anchored tier; self-attestation remains valid. It specifies how any conforming profile MAY reach the anchored tier by registering to a transparency service, and how that tier is tested (see Conformance) — so that third-party-verifiability is a property profiles can converge on, not a single format they must adopt.

Conformance Conformance is expressed as a shared vector suite: a positive composition vector (one action threaded through the populated slots) plus, per slot, the negative-case classes it MUST expose (e.g. non-deterministic encoding, ASCII-hex-as-bytes, profile-label mismatch, receipt bound to a different statement, broken join digest). A conformance vector freezes only after it has been recomputed by at least two independent implementations. This document specifies no implementation; each slot is implemented independently, and any party may verify against the vectors.

Extension Points Additional question-slots compose by the same digest discipline. Belief-provenance ("why the agent believed what it acted on") is a named extension socket. [Others as identified.]

Relationship to Existing Work This document complements, rather than replaces, existing efforts. An architecture for auditing agent delegation and interactions is developed separately (, with its interaction, action, delegation, and authorization-transition record types); record and logging formats and action-lineage protocols are defined in adjacent documents (e.g., , , — cited as live adjacent work, not positioned). The four questions here map onto those record types rather than redefining them. What this document adds is the piece those leave open: the composition of independently-verifiable profiles by a shared action-digest, a shared conformance-vector suite, and the anchored, third-party-verifiable assurance tier (see Assurance Tiers). It defines no new signing, transport, or transparency mechanism. Specific documents will be cited normatively and informatively in a later revision.

Security Considerations The security properties are those of the composed profiles plus the binding rules here; no single layer suffices. The agent is not trusted. Distributed trust roots mean no single verifier or transparency service is assumed sufficient. This document does not address an adversarial party that refuses to record at its own boundary, nor collusion across all roles, nor model alignment. [Expand.]

Privacy Considerations Records may be rich in information about users and the data an agent processed. Profiles SHOULD support content-private, hash-only (detached-payload) records so a registered statement carries only a digest, with content held under deployment controls. The shared join digest enables cross-slot correlation; pairwise or encrypted correlation identifiers SHOULD be available where correlation is not required. [Expand.]

IANA Considerations This document has no IANA actions. [A registry of slot identifiers / profile labels may be proposed in a later revision.]

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. 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. 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. CyberSecAI Ltd This document specifies a standard logging format for autonomous AI agent systems. The Agent Audit Trail (AAT) defines a JSON-based record structure with mandatory fields for agent identity, action classification, outcome tracking, and trust level reporting. Records are linked via tamper-evident hash chaining using SHA-256 per RFC 8785, with optional ECDSA signatures for non-repudiation. The format addresses requirements from the EU AI Act (Regulation 2024/1689), which mandates automatic recording of events for high-risk AI systems effective August 2026. It also maps to SOC 2 Trust Services Criteria, ISO/IEC 42001, and PCI DSS v4.0.1 logging requirements. The design is transport-agnostic and supports export to JSONL, Syslog (RFC 5424), and CSV while preserving chain integrity. Privacy is addressed through input/output hashing and tombstone- based deletion compatible with GDPR Article 17. SVT Robotics ATP defines a cryptographically verifiable directed acyclic graph (DAG) model for agent transactions. ATP enables tamper-evident signed causality and auditable lineage across agentic systems by representing each action as a signed node with one or more parent references, assuming verifier access to issuer public keys and the referenced parent nodes. The protocol is designed to be lightweight, transport-independent, and suitable for environments where accountability, provenance, and verifiable history are required. This document defines the Artificial Intelligence Governance Architecture (AIGA), an application-layer protocol for the discovery, authentication, and state management of Autonomous Agents. The protocol specifies a cryptographic handshake mechanism, a standard header schema for risk classification, and a transport-agnostic method for immutable activity logging via Merkle Trees. To address latency and enforcement concerns, this version introduces "Session Resumption" for high-frequency transactions and "Hardware-Enforced Termination" using Trusted Execution Environments (TEEs). EMILIA Protocol, Inc. A recurring pattern spans the agent-action record formats now in development: a record about an agent's action reserves a place for "the human authorization" — an approver disposition, an authority context, a human-override field, an actor slot, a signed grant, an approval reference — and leaves its semantics undefined. Each format, reasonably, does not want to specify human-authorization evidence itself; none, so far, says what filling the slot means. This document defines that one thing, host-agnostically: how any record binds named-human authorization evidence, either BY REFERENCE (a content digest of the authorization artifact's canonical bytes) or EMBEDDED (a compact, self-describing claim carrying named approvals and optional distinct-human quorum semantics), with five requirements that make the binding mean the same thing in every host: digest grounding, action agreement, verified-versus-accepted discipline, fail-closed absence, and embedded/referenced consistency. The SCITT signed-statement host family is expressed concretely (digest selection, and the observed-absence statement that is the only way absence of authorization becomes evidence); an informative appendix maps the binding onto the reserved slots of eleven current documents. This document defines no new authorization format: the referenced evidence verifies under its own specification. 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.

Acknowledgments [To be completed with the constituent-profile authors and reviewers, with permission.]