AEOESS

signal@aeoess.com https://aeoess.com

Security Individual Submission AI agent identity delegation capability attenuation governance Ed25519 signed receipts This document specifies the Agent Passport System (APS), a protocol for cryptographic identity, faceted authority attenuation, and governance for AI agent systems. APS introduces Ed25519-based agent passports, scoped delegation chains with monotonic narrowing across seven constraint dimensions (scope, spend, depth, time, reputation, values floor, reversibility), cascade revocation, a three-signature policy chain (intent, evaluation, receipt), and signed receipts that record what an agent declared, what a policy engine decided, and what an enforcement boundary observed. Authority is modeled as an element of a product lattice, and delegation is a monotone function on that lattice, ensuring that delegated capabilities can only be attenuated, never amplified. APS also defines key rotation with identity continuity, and recognizes institutional governance primitives (charters, offices, approval policies, federation) that compose with the delegation lattice; their normative specification is companion work. The protocol is intended to complement current AI agent infrastructure, including MCP and A2A, with cryptographic identity, delegated authority, and verifiable enforcement evidence. A protocol binding is specified for MCP. Reference implementations are available in TypeScript and Python under Apache-2.0; see the Implementation Status section. Beyond the authority core, this document also specifies: an external correlation form for cross-ecosystem record matching; key resolution for external and evidence signers; attestation provenance tiers; signed revocation evidence with cascade-completion records; a two-phase execution gate model; supporting signed record classes for boundary decisions, composition checks, and sampled readback; a receipt-profile mechanism illustrated by a trust-domain-gated regulated-action profile; a word-handle digest presentation; and a binding for OAuth identity-assertion authorization grants. The temporal dimension is specified as an absolute expiry bound, spend as denominated, and verification claims are expressed at named levels stating what each proves and what it does not.

Introduction AI agent systems are increasingly deployed in architectures where orchestrators decompose tasks and delegate subtasks to specialist agents. Existing agent communication protocols, including the Model Context Protocol (MCP) and the Agent-to-Agent Protocol (A2A), address connectivity and tool invocation. Deployments often need additional layers for cryptographic agent identity, delegated authority, and verifiable enforcement evidence. When an orchestrator delegates to a specialist that calls a tool, the delegation chain that led to the tool invocation is lost. APS fills this gap by providing: (1) Ed25519 cryptographic identity bound to cryptographically verifiable passports; (2) scoped delegation chains where authority narrows monotonically across seven constraint dimensions; (3) cascade revocation where revoking any delegation invalidates all descendants; (4) a three-signature policy chain binding intent to evaluation to receipt; (5) signed receipts that make each stage of a governed action verifiable after the fact; (6) institutional governance primitives for multi-agent organizations; and (7) an enforcement gateway that serves as an external reference monitor. Agentic work raises several distinct attribution questions: under whose authority an action was taken, what sources contributed to a deliverable, on whose behalf the agent acted, and who receives the value the work creates. This document specifies the authority core and the signed receipt layer through which principal resolution is recorded and other attribution axes may be referenced; it does not define contribution-attribution or beneficiary-attribution models. The protocol's formal invariants and design rationale are published in the informative references. This document is an individual submission recording the protocol as implemented; its requirement keywords constrain implementations claiming conformance to APS.

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.

Identity Scheme

Agent Passport Each agent in APS possesses an Agent Passport: a signed document binding an Ed25519 public key to an agent identifier, name, owner, and expiry time. The passport is self-signed by the agent's private key, establishing cryptographic identity without a central authority.

DID Scheme APS defines a DID method "did:aps" using multibase-encoded Ed25519 public keys: did:aps:z<base58btc-encoded-public-key>.

Key Rotation and Identity Continuity An agent MAY rotate its signing key. Rotation produces a new Ed25519 key pair while preserving the agent's identity: the agent identifier and the passport's binding to an owner persist across the rotation. The agent's DID document records the rotation, so that a verifier resolving the identity can observe the key history. A rotated key carries a retirement time. A retired key remains valid for verifying signatures produced before its retirement time, and MUST NOT be accepted for signatures produced after it. This preserves the verifiability of historical receipts and delegations signed under a key that has since been rotated out. The protocol distinguishes a planned rotation, performed on a schedule or policy, from an emergency rotation, performed in response to suspected key compromise. The two differ in operational urgency and in how aggressively a verifier should treat signatures near the retirement boundary; they do not differ in the cryptographic mechanism. Determining whether a signature was produced before or after a key's retirement time requires a trusted notion of when the signature was made. This document does not define a trusted timestamping service. A verifier evaluates retired-key validity against the signed timestamps carried by the receipt or delegation (for example, issued_at) together with any profile-defined trusted-timestamping or log-inclusion mechanism; absent such a mechanism, a verifier MUST treat signatures near the retirement boundary as it would any other claim that depends on issuer-asserted time.

Key Resolution for External and Evidence Signers Section 2.3 governs an agent's own keys. A verifier also encounters signatures from parties outside the delegation chain: evidence issuers, counterparty systems, and attesting services. For these external signers this document specifies a resolution model rather than a registry. An external signer identifier MAY be hash-bound to its subject: the identifier carries a digest of the subject identity (for example, a DID whose method-specific identifier is the SHA-256 of a server identity), and the resolver checks the presented subject against that digest before any key material is trusted. A hash-bound identifier is a binding, not a locator: key material located through the subject's own endpoint is accepted only when the subject hashes to the identifier, which closes the class of confusion in which one tenant's key material is resolved under another tenant's identifier. A hash-bound locator presented without the subject it binds MUST be rejected. Published key material MAY carry per-key validity windows. Key selection is gated on the artifact's own signed issuance time, evaluated against each key's window; a verifier MUST NOT select whichever key is current at verification time. A key set in which a key identifier is duplicated is malformed, and the duplication is an authority failure for the set as a whole, not a per-key condition. Resolution outcomes preserve failure structure. At minimum a resolver distinguishes: resolved; subject or key not found; ambiguous (including duplicate key identifiers); structurally malformed key material; transport unreachability; and an unsupported identifier scheme. Resolution is fail-closed by default. A deployment MAY adopt a fail-open policy for transport unreachability only; malformed key material that loads but is wrong is not a transient transport condition and MUST fail closed even under such a policy. A resolution outcome degraded by a fail-open policy MUST NOT be treated as a positive verification, consistent with Section 5.5.

Attestation Provenance and Composition Identity claims about an agent arrive with different evidentiary weight, and a protocol that flattens them invites over-trust. APS distinguishes four provenance tiers for attested signals: observed (the receiving infrastructure itself recorded the signal, such as transport characteristics at connection termination); infrastructure-attested (a runtime or sandbox gateway signed a claim about the agent's execution environment); provider-attested (a third-party provider confirmed a claim, such as an account or tenant relationship); and self-declared (the agent asserts the claim, unverified). In the reference implementation an attested signal carries: a signal key; a digest of the signal value rather than the raw value; its provenance tier; a verification status distinguishing cryptographically verified, observed without cryptographic proof, declared and unverified, and verification attempted but failed; a stability class indicating how long the signal remains constant; the attesting party; and issuance and expiry times. A signal's provenance tier and its verification status are independent axes: a provider-attested signal whose signature was never checked remains at declared, and a verifier MUST NOT infer verification from tier. Two attestation record shapes are published with the reference implementation. A runtime attestation is a signed claim by an attesting infrastructure party about the agent's execution environment, bound by challenge-response: it carries a nonce supplied by the requesting issuer and a digest of the subject public key, so that the attestation cannot be replayed for a different request or a different key. A provider attestation is a signed or verifiable confirmation by a third-party provider of a subject relationship, carrying a digest of the subject identifier and the verification method used. This section defines the tier and status terminology that profiles import; it does not define a general attested-signal wire format and imposes no verifier behavior beyond the tier-independence rule above. The record shapes are illustrated by the reference implementation. How a deployment weighs, combines, or scores composed attestations is deployment policy and is not specified by this document.

Delegation and Authority Attenuation

Faceted Authority Attenuation Agent authority is modeled as an element of a product lattice A = D_1 x D_2 x ... x D_7, where each D_k is a bounded partially ordered set. The seven dimensions are: Scope (power set, subset ordering), Spend (non-negative reals within a declared unit), Depth (naturals), Time (absolute expiry instant), Reputation (the closed interval from 0 to 100), Values (a values floor, defined below), Reversibility ({Tentative, Compensable, Irreversible}). The Values dimension is modeled as a values floor: a finite set of attested principle identifiers required of the agent by the delegation. Its ordering is by set inclusion, with narrowing in the superset direction. A delegation MUST preserve every principle identifier required by any ancestor and MAY add further required identifiers; it MUST NOT remove an ancestor-required identifier. Formally, if V_parent is the parent's required-principle set and V_child is the child's, a valid delegation requires V_parent is a subset of V_child. A larger values floor is a narrower authority position: more required principles constrain the agent further. The Values dimension orders sets of principle identifiers; it does not order principles against one another, and this document does not define the meaning of any individual principle identifier. The Reputation dimension is likewise carried without interpretation: this document does not define how reputation values are produced, updated, or compared across deployments beyond the interval ordering. The Time dimension is an absolute expiry instant, not a relative duration. A delegation carries an expiry as an RFC 3339 UTC timestamp; the component ordering is by instant, and an earlier expiry is a narrower authority position. A child delegation's expiry MUST be less than or equal to its parent's expiry. The child's expiry is fixed at issuance as an absolute instant. It MUST NOT be represented in the signed delegation as a duration, and MUST NOT be re-derived from a duration against any later clock reading: two relative durations issued at different times are incomparable without their issuance instants, and re-basing a duration on a later reading can extend a child's effective lifetime beyond its parent's, violating monotone narrowing. An implementation that accepts a duration as input MUST convert it to an absolute expiry at issuance, bounded by the parent's expiry, before signing. A temporal value that cannot be parsed as a valid RFC 3339 instant MUST invalidate the delegation that carries it; an implementation MUST NOT substitute a default in place of an unparseable expiry. Spend amounts are denominated. The Spend component ordering is defined only between amounts in the same unit: amounts in different units are incomparable under the lattice ordering, and this document defines no conversion between units. Once any ancestor in a delegation chain carries a spend dimension, a descendant MUST NOT change the unit at narrowing. A child MAY introduce a spend unit under an ancestor that carries no spend dimension; introducing a constraint where none existed is narrowing, not conversion. The unit in effect for a child, whether declared by the child or inherited from its parent, MUST be resolved at issuance and carried in the signed delegation; an implementation MUST NOT sign a child whose spend limit is silently reinterpreted under a different unit at a later hop. The Reputation dimension is an authority ceiling carried by the delegation: a descendant MAY lower it and MUST NOT raise it. How reputation values are computed or updated is outside this document's scope; the dimension bounds authority, it does not measure conduct. Delegation is a monotone function on this lattice: for any delegation d with parent p, auth(d) <= auth(p) in the product ordering. Authority narrows monotonically along any delegation chain across all seven dimensions simultaneously. The dimensions do not all narrow in the same set-theoretic direction: Scope narrows under subset ordering while the Values floor narrows under superset ordering. Both are valid component orderings, and the monotone-narrowing property holds across the product because the product ordering is componentwise. The componentwise argument above is self-contained; the fuller lattice formalization is developed in and .

Cascade Revocation Any delegation MAY be revoked by its issuer. Revocation MUST initiate a cascade to all transitive descendants; a cascade is complete only when the cascade-completion record of Section 3.2.1 has been emitted. Revocation is irreversible. A cascade is distinguishable as complete only through the cascade-completion record of Section 3.2.1. The enforcement gateway MUST recheck revocation status at execution time, not only at approval time.

Revocation Evidence Section 3.2 specifies revocation behavior. Behavior alone leaves a verifier dependent on the revoking system's current state; this section specifies the evidence that makes revocation history verifiable from records. The model separates two questions that MUST NOT collapse into one mutable lookup: whether a delegation is currently valid, answerable from state, and whether and why a revocation occurred, verifiable from signed records. A revocation MUST produce a signed revocation record carrying, at minimum: the revoked delegation's identity; the revocation time, inside the signed content; a reference to the revoking authority; and a machine-readable reason code, with optional free-text detail. A revocation derived from a cascade MUST additionally carry a reference to the originating revocation, so that a verifier can reconstruct from the records why a descendant delegation died. A cascade carries a transaction identity shared by every record it produces. Cascade completeness (INV-4, Section 3.3) is asserted by Section 3.2 but is not verifiable from individual revocation records: a partially revoked subtree is indistinguishable, record by record, from a completed one. A cascade therefore concludes with a signed cascade-completion record, carrying the same transaction identity, emitted after the last descendant's revocation is persistent. Its presence lets a verifier distinguish a fully closed subtree from a revocation in progress from the records alone; its absence means in progress, and a verifier MUST NOT read an incomplete record set as a closed subtree.

Core Invariants The protocol specifies eight invariants: INV-1 (Identity Verifiability), INV-2 (Scope Monotonic Narrowing), INV-3 (Spend Limit Narrowing), INV-4 (Cascade Completeness), INV-5 (Revocation Irreversibility), INV-6 (Intent-Receipt Binding), INV-7 (Authority Attribution Completeness), INV-8 (Signature Integrity). INV-6 is elaborated by the signed receipt layer specified in . The record-level verifiability of INV-4 is specified in Section 3.2.1. INV-7 (Authority Attribution Completeness) is the requirement that every governed action is attributable to an acting agent, an authority path, and a receipt context; it does not concern contribution-attribution or beneficiary-attribution, which are out of scope for this document (see Attribution Axes and Scope). INV-4 is asserted by Section 3.2 and made verifiable from records by the cascade-completion record of Section 3.2.1. INV-2, INV-3, and INV-8 are enforced at issuance, not only at verification. An issuer minting a child delegation MUST verify the parent delegation's signature and temporal validity before signing the child, and MUST refuse to issue under an expired, not-yet-valid, or revoked parent. Issuance from an expired parent MUST fail at the issuer; it MUST NOT produce a delegation whose invalidity is left for a later verifier to discover. Verification-time checking remains required (Section 3.2), but a conforming issuer does not rely on it as the sole enforcement point: a delegation that was invalid at issuance never becomes valid later.

Policy Chain APS defines a three-signature policy chain: ActionIntent (agent declares intended action), PolicyDecision (policy engine evaluates with verdict permit, deny, or narrow, where a narrow verdict grants the action at reduced authority and carries the constraints applied), PolicyReceipt (enforcement gateway records execution result). The policy engine splits into a deterministic gate (scope, signature, revocation, authority path, spend) and an advisory evaluation path (deception, proportionality). The structure and verification of the signed records produced at each stage are specified in . The spend check in the deterministic gate compares amounts only within a declared unit. When the action's declared unit and the governing delegation's declared unit differ, the gate MUST deny; it MUST NOT compare raw numeric amounts across units, and it MUST NOT apply a conversion. When the action does not declare a unit, the amount is evaluated under the delegation's resolved unit (Section 3.1); this is a defined interpretation rule, not a verifier assumption. Deployments handling monetary spend SHOULD require actions to declare their unit, and a profile MAY require the gate to deny when it is undeclared. A delegation's spend value is a limit fixed at issuance. A signed delegation is immutable and cannot carry mutable state; the cumulative amount spent under a delegation is state held at the enforcement boundary, associated with the delegation, and is not a field whose mutation the signature covers. The enforcement discipline is check-before-effect, record-after-settlement: before permitting an effect, the boundary MUST verify that the proposed amount plus the recorded cumulative total does not exceed the signed limit, and after settlement it records the settled amount. INV-3 (Section 3.3) constrains the signed limits along a chain; cumulative enforcement against those limits is an enforcement-boundary function.

Action Reference Computation Each action in the policy chain is identified by a deterministic action reference (action_ref) that serves as a cross-engine correlation anchor. The action_ref is computed as: action_ref = SHA-256(canonicalize(input_object)) where input_object is a JSON object with exactly four fields:

agentId

The DID of the acting agent (e.g., "did:aps:z6Mk..."), in the canonical string form defined by its DID method. For did:aps (Section 2.2) this is the full multibase-encoded form with no abbreviation.

actionType

The tool or action identifier string (e.g., "commerce_preflight").

scopeRequired

An array of scope strings required for this action (e.g., ["commerce:read", "commerce:write"]). Each scope string MUST be in Unicode Normalization Form C (NFC). Implementations MUST sort the array by Unicode code point before canonicalization. Scope strings are compared and sorted as-is; this document does not define case folding, and scope strings that differ only in case are distinct.

timestamp

An RFC 3339 UTC timestamp at exactly second precision, with the literal "Z" zone designator and no fractional-seconds component (e.g., "2026-04-08T12:00:00Z"). Implementations MUST format the timestamp to second precision before canonicalization; a timestamp carrying a fractional-seconds component is non-conforming.

The canonicalize function MUST follow RFC 8785 (JSON Canonicalization Scheme) . The SHA-256 hash is computed over the UTF-8 encoding of the canonicalized JSON string. The action_ref is the lowercase hexadecimal encoding of the digest. The action_ref MUST be deterministic: two input objects that are equal field-by-field, with each field in the canonical form specified above, MUST produce the same hash regardless of implementation language, JSON library, or field insertion order. Cross-engine correlation holds only when both engines reach the computation with byte-equal canonical field values; the field-form rules above exist to make that achievable across independent implementations. Implementations MUST NOT include additional fields in the input object. Implementations MUST NOT apply any transformation to field values beyond the NFC normalization of scopeRequired strings and the code-point sorting of the scopeRequired array specified above. The rules of this section define the native APS action_ref: the correlation anchor used within the APS policy chain and receipt layer. Section 4.2 defines a second, distinct correlation key with a different preimage for correlation at ecosystem boundaries. The prohibitions above apply to the native input object; they do not admit the external form of Section 4.2 as a variant of the native computation, and a value computed under one form MUST NOT be presented as the other.

External Correlation Form For correlating APS-governed actions with records produced by systems outside an APS deployment, this document defines a second deterministic reference, the external action reference, identified by the label "action-ref-v1-jcs-sha256": where canonicalize is RFC 8785 , the hash is computed over the UTF-8 encoding of the canonicalized JSON, and input_object is a JSON object with exactly four fields, named in snake_case:

action_type

The action identifier string.

agent_id

The acting agent's identifier string, in the form the correlating ecosystem uses. Unlike the native form's agentId, this document does not constrain agent_id to a DID method's canonical form.

scope

A single scope string. Unlike the native form's scopeRequired, the external form carries exactly one scope string, not an array.

timestamp

An RFC 3339 UTC timestamp at exactly millisecond precision: three fractional-second digits and the literal "Z" designator (e.g., "2026-04-08T12:00:00.000Z"). The timestamp is hashed as the byte sequence supplied. An implementation MUST reject a timestamp that does not match this shape; it MUST NOT coerce, truncate, extend, or renormalize a non-conforming value.

Field values in the external form are hashed as supplied. The external form applies none of the native form's field transformations: no Unicode normalization and no array sorting, since the scope field is a single string. The external form exists for cross-ecosystem byte parity: independent implementations outside an APS deployment compute this key from their own records, and agreement with the value carried in or derived from an APS receipt correlates the two without prior coordination. The native form of Section 4.1 remains the correlation anchor within the APS policy chain. The two forms differ in field naming, field forms, scope arity, and timestamp precision, and produce unrelated digest values for the same underlying action.

Two-Phase Execution Section 3.2 requires revocation to be rechecked at execution time, not only at approval time, and the Completion Receipt (Section 5.3.1) closes an authorize-then-complete pair. Both presuppose a gate model with two distinct enforcement moments; this section names it. In two-phase execution, the enforcement boundary first evaluates the policy chain and, on a permit or narrow verdict, issues an approval bound to the authority the verdict grants: a first-class consumable artifact, bound to the action_ref it approves, single-use, and carrying a bounded lifetime. Execution then presents and consumes the approval. At consumption the boundary MUST re-validate what can have changed since issuance, including revocation status and temporal validity, generalizing the Section 3.2 recheck. An approval that has expired, has already been consumed, or fails re-validation MUST NOT admit execution. For actions carrying a spend dimension, the two phases align with reserve-then-settle: the amount is reserved against the boundary-held cumulative total (Section 4) at approval, and settled at completion. This document specifies the gate model and its obligations; the internal mechanics of an enforcement boundary implementing it are out of scope.

Signed Receipts This section defines the signed receipt layer produced by APS policy evaluation. The policy chain of Section 4 produces a signed record at each stage; this section defines the receipt: the artifact that records what an agent declared, what a policy engine decided, and what an enforcement boundary observed. A receipt is the protocol's unit of after-the-fact verifiability. A receipt MUST be a signed object. A receipt MUST be content-addressed. A receipt MUST state the claims it carries in a form that a verifier can check without access to the system that produced it.

Receipt Envelope All APS receipts share a common envelope. The envelope binds a receipt to an issuer, a point in time, and the action it concerns, independent of the receipt's type-specific payload. The envelope contains:

receipt_id

The content address of the receipt (Section 5.2).

receipt_type

A value identifying the receipt type. Core receipt types are defined in Section 5.3; implementations MAY define additional types as described in Section 5.3.3.

issuer

The DID of the entity signing the receipt.

subject_agent

The DID of the agent whose action the receipt concerns. The issuer and the subject_agent MAY differ; for a Bilateral Receipt there are two signing parties.

action_ref

The content-addressed request identity defined in Section 4.1, identifying the action this receipt concerns.

delegation_ref

A reference to the delegation chain under which the action was taken, or to the authority basis where no delegation applies. A chain root is either APS-native, a passport-signed origination, or an imported external authority: a verified grant from an external authorization system, marked as such (Section 7.3). An imported root records that verification of the external grant was performed by the importing party; APS signature verification begins at the first APS-signed hop.

decision_ref

The decision identity binding the action to its evaluated authority and policy context. REQUIRED for receipts at or after the PolicyDecision stage. The concrete computation of decision_ref is deployment-profile-defined unless specified by a future APS profile; this document defines its role and binding semantics (Section 5.4), not a single normative computation.

issued_at

An RFC 3339 UTC timestamp.

evidence_refs

Zero or more references to artifacts the receipt relies on or records. References, not embedded content.

result

The outcome or status the receipt records, in a form determined by receipt_type.

prev

OPTIONAL. The content address of the preceding receipt in a chain, or null or absent for a chain origin or an unchained receipt (Section 5.2).

sig

A signature over the canonicalized envelope, computed with the sig field absent.

The canonicalization of the envelope for both content-addressing and signing MUST follow RFC 8785 . The signature MUST be computed as specified in Section 5.2. A receipt MUST state what it proves. A receipt MUST NOT be interpreted as proving claims outside the semantics of its receipt_type (Section 5.3).

Content Addressing and Hash Chaining A receipt's content address is computed as receipt_id = SHA-256(canonicalize(envelope without sig or receipt_id)), where canonicalize is RFC 8785 . The receipt_id MUST be deterministic: the same envelope content MUST produce the same receipt_id regardless of implementation language or JSON library. This is the same determinism property required of action_ref in Section 4.1, applied to the receipt envelope. Receipts MAY be chained. When chained, each receipt's prev field carries the receipt_id of the preceding receipt. A chain proves ordering between the receipts it links. A chain does not, by itself, prove completeness or prove that no receipt was omitted between two linked entries. A party that emits a chain selects which receipts the chain links; a verifier cannot conclude from the chain alone that no receipt was withheld. Deployments that require completeness or omission-resistance MUST specify an external mechanism that provides it, such as a monotonic sequence committed by the issuer or an append-only log with inclusion proofs. This document does not define such a mechanism. The signature over the envelope MUST be an EdDSA signature as specified in , computed over the RFC 8785 canonicalization of the envelope with the sig field absent.

Word-Handle Digest Presentation A content address is long, and human transcription of digests is a practical failure surface. A deployment MAY present a digest as a word handle: the leading bits of the digest rendered as words from a versioned, pinned lexicon, followed by checksum words derived from the rendered prefix. A handle identifies the lexicon it was rendered under; a decoder MUST reject a word not exactly present in the pinned lexicon rather than correct it, and comparison of decoded prefixes is bit-scoped to the rendered prefix length, never a raw string comparison beyond it. A word handle is a transcription and recognition aid, not a cryptographic proof: it carries only a prefix of the underlying digest. A verifier MUST NOT accept a word handle as identifying a unique receipt, record, delegation, or content object unless it has resolved the handle to the full digest or confirmed that the rendered prefix is unique within its candidate set at the time of resolution. A word handle is public: it MUST NOT be presented as a mnemonic, recovery, or seed phrase, and MUST NOT be used as secret, key, or authorization material. Presentations at common seed-phrase lengths (12, 15, 18, 21, or 24 words) MUST NOT be used.

Receipt Type Categories APS defines receipt categories at two tiers. The foundational tier covers the receipts every governed action produces. The supporting tier defines optional protocol receipt categories for deployments that need to record accountability events around an action.

Foundational Receipts

Action Receipt

Records the occurrence and outcome of a governed action. The PolicyReceipt stage of the policy chain (Section 4) is the point at which an enforcement boundary emits an Action Receipt. Action Receipt is the general category for "this governed action occurred and here is its outcome."

Authority-Boundary Receipt

Records the agent's authority position at the moment of an action: the lattice element (Section 3.1) the agent held, and which constraint dimensions bounded the action.

Completion Receipt

Records the closure of a previously authorized action, and MUST reference the receipt that authorized it. A Completion Receipt closes an authorize-then-complete pair. Not every Action Receipt is a Completion Receipt: an Action Receipt becomes a Completion Receipt only when it closes a prior authorization in this way.

Supporting Receipts

Bilateral Receipt

A receipt over an interaction between two agents, signed by both. A Bilateral Receipt proves that both parties observed the same interaction content; it does not prove either party's intent or honesty beyond that shared observation.

Custody Receipt

Records a transfer of governance custody over a data object, tool, or resource from one agent to another. Custody in this sense is the responsibility for an object under the protocol's authority model; it is not ownership, possession, or any commercial-settlement relationship.

Contestability Receipt

Records that an action, receipt, or decision can be challenged, or was challenged, under a defined governance process, together with the disposition of that challenge. It is not a payment dispute, an arbitration record, or a transactional-settlement artifact; those are outside the scope of this document.

Extension and External Representation An implementation MAY define additional receipt types. Additional types MUST use the common envelope (Section 5.1) and MUST NOT redefine the semantics of the categories above. Signed record classes that do not use the common envelope are not receipt types; they are specified as supporting signed records (Section 5.3.4) and MUST NOT be presented as envelope receipts. APS receipts MAY be represented in external attestation formats. For example, an Action Receipt MAY be expressed as an in-toto predicate for interoperability with attestation tooling that consumes that format. Such an external envelope is a representation of an APS receipt; it does not define the APS receipt taxonomy, and the categories above remain the normative reference.

Supporting Signed Records The record classes of this section are signed evidence artifacts, not receipt types under the common envelope of Section 5.1. Each carries a top-level signature field; the signature input is the RFC 8785 canonicalization of the record with that field absent, under EdDSA as in Section 5.2. Each carries the action correlation key where applicable, and MAY be referenced from receipts through evidence_refs. Whether a record class is content-addressed is defined per class by its published conformance fixtures; this document does not impose the receipt_id computation of Section 5.2 on these records. The reference implementation's type and module names for these classes predate this document's receipt-and-record boundary and include the word receipt; the boundary of Section 5.3.3, not implementation naming, is normative.

Composition-Check Record

A signed record by which an external attestor reports the outcome of named checks over an exact delegation chain, action, and context. Per-hop monotone narrowing (Section 3.1) is evaluated hop by hop; delegations that are individually rule-legal can compose toward a target that no single hop check can see, and Section 3.1 provides no per-hop mechanism to detect that. The composition-check record is the carrier for the result of whole-chain evaluation performed outside the chain. It binds a digest of the exact chain, the action_ref, and a digest of the evaluated context; it names the policy profiles and checks run as opaque versioned identifiers; and it carries one result per check from a fixed vocabulary (pass, fail, indeterminate, not checked). It carries, deliberately, no aggregate safety verdict: a pass is the named attestor's finding for one named check over the bound context, never a claim of global safety. The record declares the attestor's independence class relative to the parties in the chain; a verifier corroborates that class from its own trust context, and MUST NOT accept independence on the record's self-declaration. What the checks evaluate is attestor policy, outside this document's scope.

Accountability Record

A signed record of an enforcement-boundary decision, covering denied and halted actions as well as permitted ones. The Action Receipt (Section 5.3.1) records that a governed action occurred; a boundary that refuses or stops an action produces no Action Receipt, and without a record of the refusal the denied path is unauditable. The accountability record carries the boundary's decision from its own vocabulary, allow, deny, or halt, which is distinct from the PolicyDecision verdict vocabulary of Section 4: the verdict (permit, deny, or narrow) is the policy engine's evaluation; the decision (allow, deny, or halt) is what the enforcement boundary did. A permit or narrow verdict admits execution under the authority the verdict grants and resolves to an allow, or to a halt if the boundary stops the admitted action; a deny verdict resolves to a deny decision. The record additionally asserts, as an independent field, whether execution was observed: decision and execution status are recorded separately precisely so that a denied-but-executed event, a boundary violation, is representable rather than structurally impossible to write down. The record identifies the recorder and the recorded agent as distinct parties, carries the action_ref as its correlation key and a detached digest of the recorded action as its per-record commitment (the two are different values with different roles), and MAY carry a recorder-asserted reference to the principal; such a reference is an attribution convenience at the resolved level of Section 5.7 and does not alter that document-wide model.

Read-Fidelity Record

A signed commitment to a sampled readback challenge: evidence bearing on whether an executor read the content it claims to have read. A verifier supplies a nonce that is not derivable from the document; a seed is derived, by a stated computation, from the content digest, the presentation digest, the nonce, and a version; spans are sampled deterministically from the seed; and the record commits to the span digests and a scored k-of-n readback result. The raw span texts and responses are not in the record, only their commitments. The nonce binding is the replay defense: reusing commitments under a different nonce, content, or presentation breaks the seed derivation. This document sets no normative passing threshold; the record reports the score and the sampling parameters, and what score suffices is a deployment decision. A read-fidelity record is evidence of readback performance on the sampled spans; it is not proof of comprehension, of complete reading, or of any property of unsampled content.

Binding to action_ref, Delegation, and Policy Decision A receipt is bound to the action it concerns through three references.

action_ref

REQUIRED. Every receipt envelope carries the action_ref of Section 4.1. Two receipts carrying the same action_ref concern the same request. This is the primary correlation anchor: it allows receipts produced by independent engines, or at different stages, to be associated without prior coordination.

delegation reference

REQUIRED where the action was taken under a delegation. The receipt MUST identify the delegation chain under which the agent acted. This binds the receipt to the authority path of Section 3: a verifier can follow from the receipt to the delegation to the issuing passport.

decision reference

REQUIRED for receipts at or after the PolicyDecision stage. The receipt MUST carry the decision identity of the policy evaluation it records or follows from. The action_ref is the action correlation anchor; the decision identity binds that action reference to the evaluated authority and policy context and to the decision output. It is not a second action identifier. Two receipts carrying the same decision identity claim the same action, authority and policy context, and decision output as encoded in that decision identity. A decision identity SHOULD be content-derived: computed from the fields that constitute the decision, so that the identity is a function of what was decided rather than of where or when the record was stored, and independent parties can recompute it from the same inputs. A content-derived decision identity induces a field taxonomy on decision records: identity fields, which enter the computation and define which decision this is; ordering fields, which sequence records without changing identity; and event-instance fields, which distinguish multiple records of the same decision. Two records agreeing on identity fields are records of the same decision by construction. A reference computation with these properties is published with the reference implementation; a deployment profile MAY adopt it (see Section 11).

Through these three references a single receipt is locatable within the protocol: which request (action_ref), under whose authority (delegation), evaluated to what (decision identity).

Replay and Verification Expectations The receipt signature and the canonical envelope MUST be verifiable offline. A verifier in possession of a receipt and the issuer's public key MUST be able to confirm, without network access and without contact with the issuing system: (1) that the signature is valid over the canonicalized envelope (Section 5.2); (2) that the receipt_id matches the envelope content; (3) that the action_ref is well-formed per Section 4.1; and (4) where a prev reference is present, that it is a well-formed content address. The offline checks above establish signature validity: that the signature verifies under a public key the verifier holds. Signature validity is distinct from signer authority: possession of a key that verifies the signature does not by itself establish that the key was the authorized signing key for the claimed issuer. Where a verification decision depends on the issuer's authority and not only on the artifact's integrity, a verifier performs a further, separately named step: resolve the issuer identifier to its authorized key material through a resolution mechanism the verifier trusts, and confirm that the signing key is authorized for the artifact's own signed timestamp, evaluated against per-key validity windows rather than against whichever key is current at verification time. Signer-authority resolution has more outcomes than valid or invalid, and a verifier's result SHOULD preserve the distinction: the signature may verify under authorized, resolution-confirmed key material; the signature may verify under key material the verifier holds only by binding, with no authority resolution performed; resolution itself may fail; the resolved authority may not match the signing key or a pinned expected signer; or the signature may simply be invalid. A result in which resolution was not performed MUST NOT be reported at the same level as a result in which it succeeded. Resolution failures are fail-closed by default. A deployment MAY adopt a fail-open policy for transport unreachability only; a resolution that returns structurally invalid key material is not a transient transport condition and MUST fail closed even under such a policy. An outcome degraded by a fail-open policy MUST NOT be treated as a positive verification. Any claim that depends on external state, such as revocation status, policy registries, custody context, the resolution of a delegation chain, or referenced evidence artifacts, requires the corresponding referenced material and is therefore not verifiable from the receipt alone. The offline guarantee covers the receipt's own integrity, not the external facts the receipt references. Referenced evidence has the same structure. An evidence reference in a receipt (Section 5.1) carries a claimed content address, and the receipt signature covers the claim, not the artifact. A verifier distinguishes two evidentiary states: signature-only, in which the receipt attests a content address and no referenced artifact was retrieved and checked, and resolved, in which the artifact was retrieved, its content address recomputed, and the recomputation matched the claim. Retrieval failure, a recomputation mismatch, or the absence of a retrieval mechanism leaves the evidence at signature-only; none of these upgrades to resolved, and a mismatch is grounds to treat the reference as unverified regardless of the receipt signature's validity. Two conforming engines evaluating the same action under the same canonical input object, authority state, and policy context MUST produce receipts that agree on action_ref. Cross-engine agreement on decision identity is defined only for conforming engines operating under the same APS profile, where that profile specifies the same canonical decision input object and the same decision_ref computation (Section 5.4). This is the cross-engine replay property: within a shared profile, a second engine can re-evaluate a recorded decision and confirm agreement without coordinating with the first. This document does not define a globally interoperable decision_ref computation; cross-profile decision-identity agreement is therefore outside its scope. A verifier MUST NOT treat a valid receipt signature as evidence of the truth of the receipt's claims about the external world. A receipt signature proves that the issuer attests the payload. It does not prove the payload corresponds to external fact. The distinction between protocol-level validity and external truth is addressed in the Security Considerations.

Relationship to the Policy Chain The three-signature policy chain of Section 4, ActionIntent, PolicyDecision, PolicyReceipt, and the receipts of this section are the same structure described at two levels. The policy chain names the three signing stages of a governed action. The receipt is the signed object each stage produces and the envelope that makes it verifiable after the fact. Specifically: the ActionIntent is the agent's signed declaration; the PolicyDecision is the policy engine's signed evaluation, carrying the decision identity of Section 5.4; the PolicyReceipt is the enforcement boundary's signed Action Receipt (Section 5.3) recording execution. PolicyReceipt names the policy-chain stage at which an Action Receipt is emitted; it is not a separate receipt_type defined by this document. Invariant INV-6 (Intent-Receipt Binding, Section 3.3) is the requirement that these are cryptographically linked: the receipt at the end of the chain MUST be traceable to the intent at its start. While general receipt chaining is optional (Section 5.2), the receipts of a single policy chain MUST carry sufficient references -- through prev, action_ref, and decision_ref -- for a verifier to trace from the final receipt back to the originating ActionIntent. INV-6 is the statement of that requirement; general chaining of unrelated receipts remains at the emitter's discretion. The policy chain is therefore complete only with the receipt layer. Section 4 specifies when the signatures are produced; this section specifies what they produce and how it is verified. Without receipts, the policy chain defines a decision process but leaves no protocol-level artifact for later verification.

Attribution and Beneficiary References APS receipts identify the authority, action, and evidence associated with an agent operation. Some deployments also need to attribute the resulting deliverable, or the downstream benefit of an action, to one or more entities, including humans, organizations, agents, data sources, or tool providers. The attribution axes APS distinguishes, and the boundary of what this document specifies, are described in the Attribution Axes and Scope section. Within the receipt layer specifically, this document does not define a contribution-attribution model, a beneficiary-attribution model, or a settlement model. Implementations MAY include, in a receipt's evidence_refs (Section 5.1), references to external attribution or beneficiary records. Such records, and the allocation rules that interpret them, are expected to be specified by companion documents. A reference of this kind does not change the receipt's own semantics: a receipt continues to prove only the claim defined by its receipt_type (Section 5.3). The principal on whose behalf an agent acted is resolvable from the delegation_ref carried by the receipt: the delegation chain root identifies the authorizing principal or authority basis. Principal resolution supports two claim levels, and a resolver MUST NOT conflate them. A lineage is resolved when every hop of the referenced chain looks up successfully against the delegation records available to the resolver and the chain root maps to a known principal. Resolution is a lookup success and makes no cryptographic claim: a supplied chain that happens to match known records can be resolved without being authentic. A lineage is verified when the receipt signature verifies against the executor at the chain tail and every delegation in the traced lineage carries a valid signature by its delegator and is within its validity window. A tampered or forged chain cannot be verified. Verified attests the authenticity and temporal validity of the lineage signatures; it does not by itself attest that the action was within the delegated scope, that scope narrowed between hops, or that no delegation in the lineage was revoked, each of which is a further check against the corresponding material (Section 5.5). Lineage reporting MUST be deterministic: the same receipt and the same delegation records MUST produce the same reported lineage, independent of record ordering, and the reported hop at the chain tail MUST be consistent with the delegation reference the receipt itself carries. Where multiple delegation records match a hop, the authenticity property is evaluated against the set (some valid matching record suffices; no valid matching record breaks it), so that a duplicate or re-issued record can neither manufacture nor destroy verification. This document does not define a separate principal field on receipts. Deployments that need faster lookup MAY denormalize the chain root into a profile-defined field, but such a field is a convenience copy at the resolved level at most; it does not replace verification of the delegation chain. Allocation of work, credit, benefit, compensation, ownership, or liability across beneficiaries or other attribution recipients remains out of scope for this document.

Receipt Profiles A receipt profile is a named, versioned set of additional constraints over the receipt layer: which fields are required, which external anchors must be present, and what claim vocabulary the result is expressed in. The result classifications a profile defines are its dispositions. A profile strengthens what a receipt can claim without changing the base semantics of Sections 5.1 through 5.7. Profiles are identified by a version-carrying identifier, and a receipt evaluated under a profile names the profile it was evaluated under. One profile with these properties, the regulated-action profile, is published with the reference implementation and illustrates the mechanism. Its core device is trust-domain counting: the profile counts the distinct trust domains, relative to the operator, from which the action's supporting attestations originate, for example an external identity provider asserting the acting identity and the target resource's system of record confirming the effect against a key registered independently of the operator. The profile's strong disposition is gated on attestations from at least two distinct trust domains; below that threshold the result is expressible only in dispositions that name the weaker basis, such as self-attested or authority-bound. An operator-anchored copy of an external assertion does not count as a second domain. Two trust domains are distinct, relative to the operator, when their attesting keys are controlled and published independently of the operator and of each other; the profile's versioned identifier defines the concrete distinctness test. A profile disposition is a profile-scoped result label: it does not replace the receipt's result field, and it is distinct from the verdict vocabulary of Section 4, the boundary-decision vocabulary of Section 5.3.4, and the claim levels of Section 5.7. The profile additionally requires hash-committed intent pre-commitment, with the committed intent temporally ordered before the resource event, and its result always carries an explicit statement that correctness of the agent's judgment is not claimed. The full disposition vocabulary is defined by the profile's versioned identifier, published with the reference implementation, and is not frozen into this document. A verifier evaluating the profile is stateless over supplied inputs; how those inputs are gathered and reconciled is deployment machinery outside this document's scope.

Institutional Governance Deployments serving multi-agent organizations often need structure above the level of a single delegation chain: a charter that bounds what an organization's agents may do, offices that hold standing authority, approval policies, succession, and federation across organizations. APS is designed so that such structures compose with the delegation lattice rather than sitting beside it: each layer constrains the one below it -- a charter constrains offices, an office constrains the delegations issued under it, a delegation constrains actions -- and each containment relation is an ordering relation in the product lattice of Section 3.1, so the monotone-narrowing property holds across the full institutional structure and not only across direct delegation chains. This document does not normatively specify the institutional structures themselves -- their wire formats, their lifecycle, or their individual semantics. It specifies only that they compose with the delegation lattice under componentwise ordering. The normative specification of institutional governance structures is companion work.

Protocol Bindings

MCP Binding APS specifies a binding to MCP. APS provides an MCP server that acts as the enforcement gateway. For the purposes of this binding, a privileged action is any action the policy chain (Section 4) is configured to evaluate, including any action whose required scope is non-empty in the Scope dimension of the authority lattice (Section 3.1). In an APS-mediated MCP deployment, privileged actions covered by APS policy MUST pass through the gateway, which validates the delegation chain, evaluates the policy chain, and generates signed receipts. In deployments where the gateway is the exclusive holder of the target API credentials, the agent cannot bypass the gateway for those privileged actions; this exclusivity is a deployment precondition of the kind Section 8 describes, not an unconditional property of the binding.

Other Bindings A binding to A2A exists in the reference implementation and is not normatively specified here. Section 7.3 specifies a binding for OAuth identity-assertion authorization grants. Other protocol bindings are not specified by this document.

OAuth Identity-Assertion Grant Binding Deployments in which an agent's authority originates from an enterprise authorization system need the delegation chain to begin from that system's grant rather than from an APS-native passport. This section specifies the binding for an OAuth identity-assertion authorization grant , pinned to an identified draft version of that specification. The binding is verifier-first: the importing party verifies the external grant by that specification's own rules before any APS structure is built, and APS records the verification rather than performing it. The record of verification is a caller-signed attestation, an accountability artifact naming the grant reference and the verification time under the importing party's own key, so that the party on the hook for the verification is identifiable. The binding does not re-verify the grant, and a binding result is never collapsed to a single safe-for-execution boolean; it reports what was projected and under what basis. Two anchors are kept separate and MUST NOT be merged. The source grant reference is a digest over a committed preimage of the grant's provenance fields, its issuer, subject, grant identity, client, and audience, and never covers scope, spend, chain content, or receipt content. The delegation chain root is the canonical content digest over the APS-signed hops built under the imported grant. The first identifies where authority came from; the second identifies what was built under it; conflating them makes chain content unrecomputable from the records. Scope projection from the external grant into the APS Scope dimension is lossy, and the binding preserves the grant's authorization details verbatim alongside the projection rather than pretending the projection is complete. A spend dimension MUST NOT be invented at import: an external grant that carries no spend semantics yields a chain root with no spend dimension, which under Section 3.1 a descendant may narrow by introducing one. The grant's audience is carried in the binding but not enforced by it; the relying party at the point of use MUST reject an audience mismatch.

Security Considerations The protocol's strongest guarantees hold when all privileged effects are mediated by the ProxyGateway enforcement boundary. When agents use the SDK voluntarily without an external gateway, guarantees are conditional on agent cooperation. The threat model defines four attacker classes: adversarial agent, messaging attacker, runtime attacker, and compromised-but-signing agent. Runtime compromise is out of scope for protocol guarantees. The compromised-but-signing agent is a hijacked agent producing cryptographically valid signatures over false claims about its own state. The agent's signature verifies because the key is uncompromised, but the signed claims (instruction context observed, decision process attested, action taken under declared instruction X) may be false. Closure of this attack class requires evidence signed from outside the compromised agent's trust domain. This document now specifies several mechanisms of that shape: signer-authority resolution distinct from signature validity (Section 5.5), the resolved-versus-verified claim levels for lineage (Section 5.7), receipt profiles that gate finality on attestations from two or more distinct trust domains (Section 5.8), and composition-check records carrying an attestor-independence class (Section 5.3.4). These narrow the attack surface; they do not close it. A single-domain deployment remains exposed to the compromised-but-signing agent, and fully general operationally-independent witnessing of agent state remains future work (). This epistemic boundary extends to signed receipts. The gap between what a cryptographic governance protocol can prove and what it cannot is analyzed in . A signed receipt attests what the policy chain observed and decided. It does not attest ground truth about the external world. A valid receipt signature proves that the issuer attests the receipt's payload; it does not prove the payload corresponds to external fact. Verifiers MUST treat receipts as evidence of what was attested, not as proof of what is true. Signed governance mutations are exposed to a substitution class when an approval signature binds an identifier and a description rather than the mutated content itself. An approver who signs a proposal identifier can have a different proposal body substituted under the same identifier between approval and application. Approval signatures over any governance mutation SHOULD bind the full proposed content and the version transition it applies to, not a reference to them. The normative preimage for specific governance structures is companion work (Section 6); the consideration applies to any signed mutation of standing authority. Where a deployment issues consumable challenge, token, or approval artifacts carrying an expiry (for example, the approval artifact of Section 4.3, or challenge artifacts in a protocol binding), verifiers MUST enforce the expiry, and issuance against an expired or unparseable challenge MUST fail closed. An expiry that is carried but not enforced is equivalent to no expiry. The external correlation form (Section 4.2) hashes fields as supplied by the correlating ecosystem. A matching external action reference is evidence of correlation between records, not of the authenticity, authority, or integrity of either record, and it MUST NOT be treated as an authority claim; correlation strength is bounded by the external ecosystem's own field discipline. Read-fidelity records (Section 5.3.4) are challenge evidence, not proof of perception. Their strength rests on nonce unpredictability and on the seed binding to both the content and presentation digests: a reused or predictable nonce permits precomputation, and content the executor has previously observed can be answered from memory rather than from the presented artifact. A verifier relying on a read-fidelity record MUST treat nonce freshness and presentation binding as part of the trust decision, and SHOULD treat readback of previously published content as weaker evidence than readback of content novel to the executor. An imported external chain root (Section 7.3) relocates the root of trust for the chain built under it: APS signature verification begins at the first APS-signed hop, and the standing of everything above that hop rests on the importing party's verification of the external grant. The caller-signed verification attestation exists to make that party identifiable; a verifier that accepts imported roots accepts the importing party as a trust anchor for those chains, and SHOULD treat the attestation as the auditable record of that acceptance. A verifier that has not itself verified the external grant under its native rules holds the imported root at the strength of the importer's claim, and an audience check omitted at the point of use can admit a grant outside its intended audience.

IANA Considerations This document has no IANA actions. DID methods are recorded in the W3C DID Specification Registries rather than through IANA. The string vocabularies this document defines or references, including provenance tiers, resolution outcomes, check-result values, profile dispositions, and the external correlation label, are versioned identifiers published with the reference implementation; establishing a registry for them is future work.

Attribution Axes and Scope APS distinguishes four attribution axes for agentic work. They are distinct because, in multi-party workflows, they may resolve to different entities.

Authority

The delegation chain under which an action was permitted. This document specifies the authority axis in full (Sections 3 and 4).

Contribution

The sources, such as data, models, tools, or prior work product, that fed into a deliverable. This document does not specify a contribution-attribution model.

Principal

The entity on whose behalf, or under whose account, the agent acted. The principal is resolvable from the delegation chain root referenced by the receipt envelope, at either of two claim levels, resolved or verified, defined in .

Beneficiary

The entity that receives the value, credit, or downstream benefit the work creates. This document does not specify a beneficiary-attribution model.

The distinction between the principal and the beneficiary is structurally load-bearing. An agent may act on behalf of an authorizing principal, such as a consulting firm, to produce a deliverable whose beneficiary is a third party, such as that firm's client. A protocol that collapses the two axes cannot represent this ordinary case. The authority and principal axes are resolvable from the mechanisms this document defines when the referenced delegation material is available. The contribution and beneficiary axes are recognized as first-class attribution layers of APS whose normative mechanics are left to companion specifications. The allocation of credit, benefit, compensation, liability, or ownership across beneficiaries is out of scope for this document and is not implied by the authority chain.

Future Work Future work includes wire-format epistemic discipline: typed claim and evidence labels that make explicit what each signed artifact proves and what it does not prove. This document now specifies normative instances of that discipline, the resolved-versus-verified claim levels for principal resolution (Section 5.7) and the claimed-versus-resolved states for referenced evidence (Section 5.5); generalizing those labels into a uniform normative wire vocabulary across all artifact types remains future work. A normative, globally interoperable decision_ref computation remains deferred; a content-derived reference computation with the properties of Section 5.4 is published with the reference implementation, and adopting it normatively is profile work. The contribution-attribution and beneficiary-attribution layers (Attribution Axes and Scope) and the normative specification of institutional governance structures (Section 6) remain companion work. Operationally-independent witnessing of agent state, identified in earlier revisions of this document as an open architectural direction, is now partially specified: signer-authority resolution (Sections 2.4 and 5.5), attestation provenance tiers (Section 2.5), trust-domain-gated receipt profiles (Section 5.8), and composition-check records with attestor-independence classes (Section 5.3.4). Fully general witnessing of a compromised-but-signing agent's internal state remains open, and this document does not claim it.

References Normative References Informative References

Implementation Status Reference implementations of APS are available in TypeScript and Python, published as open-source packages under Apache-2.0: the TypeScript SDK and the Python SDK are both published as "agent-passport-system" on npm and PyPI respectively, and an MCP server binding is published as "agent-passport-system-mcp" on npm. The implementations carry a conformance test suite and a published conformance fixture set. Current versions, test counts, tool counts, and conformance results are maintained at the project repository: https://github.com/aeoess/agent-passport-system.