Network Working Group T. Trujillo Internet-Draft Individual Submission Intended status: Informational 4 September 2026 Expires: 8 March 2027 Agent-to-Agent Trust, Identity, and Verifiable Provenance draft-tonyai-a2a-trust-03 Abstract This document defines a trust model for agent-to-agent (A2A) interactions in multi-agent AI systems. It specifies how agents obtain verifiable identities via CA-signed templates, how spawn chains are cryptographically established and validated, how dynamic policies are governed under a dual-signature model, and how cross- organizational agent interactions are explicitly authorized. The model applies existing PKI primitives (X.509, CRL, CSR) and established identity patterns (OAuth 2.0, On-Behalf-Of) to the problem of agent provenance. This document does not address agent- to-resource access control, human-in-the-loop orchestration, or agent behavior, as those concerns belong to the resource enforcement layer and the orchestration layer respectively. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Trujillo Expires 8 March 2027 [Page 1] Internet-Draft A2A Trust September 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Document Encoding . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Signature Envelope . . . . . . . . . . . . . . . . . . . 5 3.2. Wire Names . . . . . . . . . . . . . . . . . . . . . . . 7 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 10 6. Existing Patterns and Gaps . . . . . . . . . . . . . . . . . 10 6.1. On-Behalf-Of (OBO) . . . . . . . . . . . . . . . . . . . 10 6.2. OAuth 2.0 Token Exchange (RFC 8693) . . . . . . . . . . . 11 7. Agent Identity . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Certificate Profile . . . . . . . . . . . . . . . . . . . 11 7.2. Binding Identity to the Certificate . . . . . . . . . . . 13 7.3. Certificate Signing Request Flow . . . . . . . . . . . . 13 7.4. Certificate Chain Structure . . . . . . . . . . . . . . . 14 8. Template Structure . . . . . . . . . . . . . . . . . . . . . 15 8.1. Static Fields . . . . . . . . . . . . . . . . . . . . . . 15 8.2. Encoding of Static Fields . . . . . . . . . . . . . . . . 17 8.3. Dynamic Policy Bounds . . . . . . . . . . . . . . . . . . 19 9. Template Authoring and Attestation . . . . . . . . . . . . . 20 9.1. Conformance Gate . . . . . . . . . . . . . . . . . . . . 20 9.2. Dual Attestation . . . . . . . . . . . . . . . . . . . . 20 9.3. Issuance . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Spawn Chain Validation . . . . . . . . . . . . . . . . . . . 22 10.1. Two-Check Spawn Rule . . . . . . . . . . . . . . . . . . 22 10.2. Spawn Validation Sequence . . . . . . . . . . . . . . . 22 10.3. Scope Constraint . . . . . . . . . . . . . . . . . . . . 24 10.4. Audit Requirements . . . . . . . . . . . . . . . . . . . 25 10.5. Encoding of Spawn Provenance . . . . . . . . . . . . . . 27 11. Dynamic Policy Governance . . . . . . . . . . . . . . . . . . 29 11.1. Two-Lane Model . . . . . . . . . . . . . . . . . . . . . 29 11.2. Ownership . . . . . . . . . . . . . . . . . . . . . . . 29 11.3. Dual Signature Requirement . . . . . . . . . . . . . . . 29 11.4. Dynamic Policy Document Structure . . . . . . . . . . . 29 11.5. Canonicalization . . . . . . . . . . . . . . . . . . . . 31 11.6. Signature and Hash Coverage . . . . . . . . . . . . . . 31 11.7. Policy Change Sequence . . . . . . . . . . . . . . . . . 32 Trujillo Expires 8 March 2027 [Page 2] Internet-Draft A2A Trust September 2026 11.8. Threat Coverage . . . . . . . . . . . . . . . . . . . . 33 12. Template Versioning . . . . . . . . . . . . . . . . . . . . . 35 12.1. Full Re-Verification Required . . . . . . . . . . . . . 35 12.2. Versioning Principle . . . . . . . . . . . . . . . . . . 35 12.3. Non-Inheritance Rules . . . . . . . . . . . . . . . . . 35 12.4. Template Lifecycle . . . . . . . . . . . . . . . . . . . 36 12.5. Cross-Organizational Grant Re-Issuance . . . . . . . . . 36 13. Cross-Organizational Agent Interaction . . . . . . . . . . . 36 13.1. Explicit Grant Requirement . . . . . . . . . . . . . . . 36 13.2. Grant Structure . . . . . . . . . . . . . . . . . . . . 36 13.3. Trust Anchor Options . . . . . . . . . . . . . . . . . . 38 13.4. Unilateral Revocation . . . . . . . . . . . . . . . . . 38 13.5. Federated Audit . . . . . . . . . . . . . . . . . . . . 38 14. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . 38 14.1. Template Revocation . . . . . . . . . . . . . . . . . . 38 14.2. Individual Agent Revocation . . . . . . . . . . . . . . 39 14.3. Automation Requirement . . . . . . . . . . . . . . . . . 39 14.4. Locating Revocation State . . . . . . . . . . . . . . . 39 15. Failure Model . . . . . . . . . . . . . . . . . . . . . . . . 39 15.1. Fail Closed . . . . . . . . . . . . . . . . . . . . . . 39 16. Conformance Requirements . . . . . . . . . . . . . . . . . . 40 16.1. Field Placement . . . . . . . . . . . . . . . . . . . . 40 16.2. CSR Validation . . . . . . . . . . . . . . . . . . . . . 40 16.3. Test Vectors . . . . . . . . . . . . . . . . . . . . . . 40 16.4. Conformance Claims . . . . . . . . . . . . . . . . . . . 40 16.5. Reference Implementation . . . . . . . . . . . . . . . . 40 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 17.1. Object Identifier . . . . . . . . . . . . . . . . . . . 41 17.2. Media Type Registration . . . . . . . . . . . . . . . . 41 17.3. Agent Scope Registry . . . . . . . . . . . . . . . . . . 42 18. Implementation Status . . . . . . . . . . . . . . . . . . . . 42 19. Security Considerations . . . . . . . . . . . . . . . . . . . 44 19.1. Scope Escalation . . . . . . . . . . . . . . . . . . . . 44 19.2. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 44 19.3. Compromised Templates . . . . . . . . . . . . . . . . . 45 19.4. Single Point of Compromise . . . . . . . . . . . . . . . 45 19.5. Cross-Organizational Trust . . . . . . . . . . . . . . . 45 19.6. PKI Does Not Enforce Authorization . . . . . . . . . . . 45 19.7. Audit Integrity . . . . . . . . . . . . . . . . . . . . 46 19.8. Privacy Considerations . . . . . . . . . . . . . . . . . 46 19.9. Algorithm Agility . . . . . . . . . . . . . . . . . . . 47 19.10. Parsing Untrusted Input . . . . . . . . . . . . . . . . 47 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 20.1. Normative References . . . . . . . . . . . . . . . . . . 47 20.2. Informative References . . . . . . . . . . . . . . . . . 49 Appendix A. Changes since draft-tonyai-a2a-trust-02 . . . . . . 49 Appendix B. Changes since draft-tonyai-a2a-trust-01 . . . . . . 54 Appendix C. Changes since draft-tonyai-a2a-trust-00 . . . . . . 56 Trujillo Expires 8 March 2027 [Page 3] Internet-Draft A2A Trust September 2026 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 57 1. Introduction Multi-agent AI systems introduce identity and authorization gaps that existing standards do not fully address. When Agent A spawns Agent B, and Agent B calls a resource, no current standard defines how the resource verifies that Agent B was legitimately spawned, that its scope has not been escalated, or that its origin template is trusted. This document proposes a trust model based on: * Agent templates as first-class, CA-signed identity artifacts. * Verifiable spawn chains where each agent's provenance is cryptographically traceable to a registered template. * Two-lane governance separating static identity (cert-based) from dynamic policy (policy-engine gated). * Fail-closed enforcement at every verification step. The model reuses proven PKI primitives and applies them to a new surface -- agent identity -- rather than inventing new cryptographic mechanisms. 2. Conventions Used in This Document 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Document Encoding Every document defined by this specification -- the Agent Template extension of Section 8.2, the Agent Spawn extension of Section 10.5, the dynamic policy document of Section 11.4, the cross-organizational grant of Section 13.2, and the audit log entry of Section 10.4 -- is a JSON object serialized using the JSON Canonicalization Scheme (JCS) [RFC8785]. Trujillo Expires 8 March 2027 [Page 4] Internet-Draft A2A Trust September 2026 Field names in the tables of this document are display names, written for a reader. The corresponding wire names are lowercase, use underscore as the word separator, and are given in Table 3. A relying party MUST compare wire names exactly and MUST NOT apply case folding, Unicode normalization, or any other transformation before comparison. The same rule governs every string value this document compares for equality: an agent identifier, an Owner, an OrgID, a Grantor or Grantee, a scope, a nonce, an outcome. Two values are equal when their octets are identical, and a relying party MUST NOT apply case folding, Unicode normalization, trimming, or any other transformation to either before comparing them. Where a later section restates this for one value, it does so for emphasis, not because the rule differs there. A JSON object carried under this specification MUST NOT contain a duplicate member name, which [RFC8785], Section 3.1, also requires of any input to JCS. A relying party MUST detect a duplicate and refuse the document. This is a requirement on the parser, not only on the document: JSON syntax permits duplicates, and a parser that silently keeps the first or the last occurrence does not satisfy it. Two such parsers disagree about what was signed while both report success, which is the failure this rule exists to prevent. Every timestamp carried under this specification is an [RFC3339] date-time in UTC using the Z designator. A relying party MUST refuse a timestamp carrying a numeric offset, a lowercase designator, or no designator: a time is compared byte-for-byte in a signed body, and one instant with two spellings is two instants to a signature. Fractional seconds MAY be present. The JSON objects this document defines are flat. Their members are strings, integers, or arrays of strings, as the tables specify, and nothing else. A relying party MUST refuse an object carrying a nested object, an array of anything other than strings, a null, a boolean, or a non-integer number, before any further processing. A parser that will accept only the shapes this document defines has no depth to exhaust and no type to confuse. 3.1. Signature Envelope A signed document is carried inside an envelope: a JSON object whose members are the signed document itself and the values that attest to it. The envelope members are named as follows. These names are REQUIRED; a relying party MUST refuse an envelope carrying any member not listed here. Trujillo Expires 8 March 2027 [Page 5] Internet-Draft A2A Trust September 2026 +==============+========+=========================================+ | Member | Type | Content | +==============+========+=========================================+ | body | object | The signed document: a template, a | | | | policy, or a grant | +--------------+--------+-----------------------------------------+ | owner_sig | string | Signature by the template Owner | +--------------+--------+-----------------------------------------+ | pa_sig | string | Signature by the Policy Authority | +--------------+--------+-----------------------------------------+ | content_hash | string | SHA-256 digest of the signed octets, | | | | lowercase hexadecimal. REQUIRED in the | | | | envelope of a dynamic policy document; | | | | MUST be absent from the envelope of a | | | | template or a grant (Section 11.6) | +--------------+--------+-----------------------------------------+ Table 1: Envelope Members Every signature, and the content hash, is computed over the same octet string: the JCS serialization of body, and nothing else. The other envelope members are outside body and therefore never inside a preimage. A signature cannot cover itself, and an implementation that signs the whole envelope produces a value no verifier can reproduce. The rule that a document carrying an undefined field MUST be refused applies to body; the envelope members are not fields of the document they attest to. Each signature member MUST be a string containing the base64 encoding [RFC4648] of the raw signature value, without line breaks and without PEM framing. A relying party MUST refuse an envelope whose owner_sig and pa_sig verify under the same public key: the subjectPublicKeyInfo of the Owner certificate and of the Policy Authority certificate MUST differ. Two roles satisfied by one key is one role. The comparison is of keys, not of signature octets: a randomized signature scheme produces different octets from one key on every signing, so equal signatures would never be observed even when a single key holds both roles. The signature algorithm is determined by the type of the signer's public key, as carried in the signer's certificate, and is not signalled in the envelope. A signer MUST use, and a relying party MUST verify with, exactly the algorithm this table assigns; any other combination MUST be refused. Trujillo Expires 8 March 2027 [Page 6] Internet-Draft A2A Trust September 2026 +==============+=========================+=======================+ | Signer key | Algorithm | Signature value | +==============+=========================+=======================+ | RSA, 3072 | RSASSA-PSS with SHA- | The PSS signature | | bits or more | 256, MGF1 with SHA-256, | octets | | | salt length 32 octets | | +--------------+-------------------------+-----------------------+ | EC, curve | ECDSA with SHA-256 | r and s, each 32 | | P-256 | | octets, concatenated: | | | | 64 octets | +--------------+-------------------------+-----------------------+ | EC, curve | ECDSA with SHA-384 | r and s, each 48 | | P-384 | | octets, concatenated: | | | | 96 octets | +--------------+-------------------------+-----------------------+ | Ed25519 | Ed25519 (PureEdDSA) | The 64-octet EdDSA | | | [RFC8032] | signature | +--------------+-------------------------+-----------------------+ Table 2: Signature Algorithm by Key Type Fixing the digest to the key type is what allows the envelope to carry no algorithm identifier: a verifier learns everything it needs from the certificate it has already validated, and an attacker cannot negotiate a weaker algorithm because there is nothing to negotiate. ECDSA values are the fixed-width concatenation rather than DER, so that a signature has exactly one encoding. RSASSA-PSS is specified rather than RSASSA-PKCS1-v1_5 because PSS carries a security proof and is the scheme new profiles adopt; a relying party MUST refuse a PKCS1-v1_5 signature even when it verifies. PSS is randomized: the same key and body produce a different signature on each signing, so a test vector verifies a signature rather than comparing its octets. 3.2. Wire Names The following table gives the wire name for every display name used in this document. Where a display name appears in more than one document it has the same wire name in each. +=====================+======================+=====================+ | Display name | Wire name | Defined in | +=====================+======================+=====================+ | Subject | subject | Sections 8.1, 11.4 | +---------------------+----------------------+---------------------+ | Owner | owner | Sections 8.1, 11.4 | +---------------------+----------------------+---------------------+ | OrgID | org_id | Sections 8.1, 11.4 | +---------------------+----------------------+---------------------+ Trujillo Expires 8 March 2027 [Page 7] Internet-Draft A2A Trust September 2026 | PermittedOperations | permitted_operations | Section 8.1 | +---------------------+----------------------+---------------------+ | AllowedScopes | allowed_scopes | Sections 8.1, 13.2 | +---------------------+----------------------+---------------------+ | CanSpawn | can_spawn | Section 8.1 | +---------------------+----------------------+---------------------+ | MaxChildren | max_children | Section 8.1 | +---------------------+----------------------+---------------------+ | PolicyRef | policy_ref | Section 8.1 | +---------------------+----------------------+---------------------+ | TTL | ttl_seconds | Sections 8.1, 13.2 | +---------------------+----------------------+---------------------+ | Scopes | scopes | Section 11.4 | +---------------------+----------------------+---------------------+ | SpawnTargets | spawn_targets | Section 11.4 | +---------------------+----------------------+---------------------+ | Version | version | Section 11.4 | +---------------------+----------------------+---------------------+ | IssuedAt | issued_at | Sections 11.4, 13.2 | +---------------------+----------------------+---------------------+ | NotAfter | not_after | Section 11.4 | +---------------------+----------------------+---------------------+ | Grantor | grantor | Section 13.2 | +---------------------+----------------------+---------------------+ | Grantee | grantee | Section 13.2 | +---------------------+----------------------+---------------------+ | Template | template | Section 13.2 | +---------------------+----------------------+---------------------+ | MaxSpawns | max_spawns | Section 13.2 | +---------------------+----------------------+---------------------+ | GrantID | grant_id | Sections 13.2, 10.5 | +---------------------+----------------------+---------------------+ | ParentAgentID | parent_agent_id | Section 10.5 | +---------------------+----------------------+---------------------+ | SpawnedAt | spawned_at | Section 10.5 | +---------------------+----------------------+---------------------+ | SpawnNonce | spawn_nonce | Section 10.5 | +---------------------+----------------------+---------------------+ Table 3: Display Name to Wire Name 4. Terminology Agent: An ephemeral, autonomous process that performs tasks on behalf of a user or another agent. Agent Template: A CA-signed artifact defining exactly one agent's Trujillo Expires 8 March 2027 [Page 8] Internet-Draft A2A Trust September 2026 identity, allowed scopes, spawn rules, and policy reference. A template is not a class from which many agents are made: its Subject is the identifier of the one agent it defines, and spawning from a template instantiates that agent. A deployment wanting many similar agents registers many templates. Relying Party: Any party that validates an agent's certificate, chain, policy, or grant in order to decide whether to act on it -- a resource, a Registry evaluating a spawn request, or another agent. Owner: The party responsible for a template, identified by the template's Owner field and holding the private key of the Owner certificate described in Section 9.2. Orchestrator: An agent that spawns other agents. The figures in this document use the bare term for any such agent; the Root Orchestrator is the one with no parent. Root Orchestrator: An agent that has no parent. Its certificate carries no Agent Spawn extension (Section 10.5). Template Registry: The authoritative store of approved, signed agent templates for an organization. Template Registry CA: The Certificate Authority that signs agent templates -- the root of trust for the agent ecosystem. Spawn: The act of an agent instantiating a child agent from an approved template. Spawn Chain: The ordered, cryptographically verifiable sequence of agents from the root orchestrator to the current agent. Policy Authority: The entity responsible for countersigning dynamic policy changes after automated gate validation. CRL: Certificate Revocation List -- the list of revoked template and agent certificates maintained by the CA. CSR: Certificate Signing Request -- the template author's request to the CA for a signed template certificate. Cross-Org Grant: An explicit, signed authorization allowing agents from one organization to spawn from a template owned by another. Trujillo Expires 8 March 2027 [Page 9] Internet-Draft A2A Trust September 2026 The Template Registry and the Template Registry CA are described as one logical entity throughout this document -- "the Registry" -- that stores templates, evaluates spawn requests, and issues certificates. A deployment may separate them; the interface between them is outside this document, and every requirement placed on "the Registry" applies to that entity as a whole. 5. Problem Statement Multi-agent orchestration creates identity and authorization gaps: Agent A --> spawns --> Agent B --> calls --> Resource Figure 1 * Which identity does the Resource see? * How does authorization propagate across the chain without escalating? * If Agent B is compromised, can it impersonate Agent A? * Who owns the audit trail across the full chain? * How does the Resource prove Agent B was authorized to be spawned? The author is not aware of a standard, from the W3C, the IETF, or a vendor, that fully addresses agent provenance in multi-hop chains. 6. Existing Patterns and Gaps Several systems address a neighbouring problem. Workload identity frameworks such as SPIFFE [SPIFFE] issue verifiable identities to services but do not model one service spawning another under a bounded delegation. Relationship-based authorization systems such as OpenFGA [OpenFGA] evaluate what an identity may do but assume the identity is already established. PKI secrets engines such as Vault [VAULTPKI] issue certificates on request but leave the content of a certificate to the requester. This document assumes the zero-trust posture of [NIST800-207], in which no request is trusted for where it came from, and applies it to the question those systems leave open: how an agent proves what authority it was granted, and by whom. 6.1. On-Behalf-Of (OBO) Microsoft Entra ID OBO provides user-to-service delegation: Trujillo Expires 8 March 2027 [Page 10] Internet-Draft A2A Trust September 2026 User --> Agent A (token A) --> Agent A requests token for Agent B on behalf of user --> Entra validates the chain --> Issues scoped delegated token Figure 2 Key insight: a trusted third party validates the delegation chain. Agents do not self-assert trust. OBO breaks down for agent-to-agent because agents are ephemeral, agent spawning is dynamic, and no registry exists for agent templates. 6.2. OAuth 2.0 Token Exchange (RFC 8693) OAuth 2.0 [RFC6749] Token Exchange [RFC8693] defines scope constraint across delegation hops -- downstream tokens MUST be a subset of upstream grants. This document adopts that principle for agent scope inheritance. 7. Agent Identity Agent identity MUST be established using X.509 certificate chains [RFC5280]. This reuses the same trust model used by TLS and existing workload identity systems. 7.1. Certificate Profile Certificates used for agent identity MUST conform to [RFC5280]. In addition, a relying party validating an agent certificate MUST enforce all of the following, and MUST refuse the certificate if any is not satisfied: * An agent certificate MUST carry the basicConstraints extension asserting cA = FALSE. A certificate that omits basicConstraints MUST be refused; the extension's absence MUST NOT be treated as equivalent to cA = FALSE. * A Template Registry CA certificate MUST carry basicConstraints asserting cA = TRUE, marked critical, and MUST assert keyCertSign in its keyUsage extension. * Certificates MUST be signed using SHA-256 or a stronger digest. Certificates signed with SHA-1 or MD5 MUST be refused irrespective of key size. Trujillo Expires 8 March 2027 [Page 11] Internet-Draft A2A Trust September 2026 * Public keys MUST provide at least a 128-bit security level as defined in [SP800-57]: RSA with a modulus of 3072 bits or more, an EC key on P-256 or P-384, or an Ed25519 key [RFC8410]. A relying party MUST refuse a certificate whose key falls below this level, including an RSA key of 2048 bits. EC and Ed25519 keys are RECOMMENDED over RSA: they reach the floor with smaller certificates and faster generation, and Ed25519 signatures are deterministic. * An agent certificate MUST carry the keyUsage extension, marked critical, asserting digitalSignature and no other bit. keyCertSign and cRLSign MUST NOT be asserted on an agent certificate; a relying party MUST refuse one that asserts either, independently of the basicConstraints check above. * The serialNumber MUST contain at least 64 bits of output from a cryptographically secure random number generator. A predictable serial number is an input an attacker controls when searching for a digest collision over a certificate. The value is an ASN.1 INTEGER, which [RFC5280] requires to be positive, at most 20 octets, and in minimal DER form. An implementation that clears the top bit of the first random octet to keep the value positive discards a bit of entropy and, one draw in 256, produces a leading zero octet followed by an octet below 0x80 -- a non-minimal encoding that a strict parser refuses. Draw the random octets, at most 19 so that a prepended octet stays within the limit; strip any leading zero octets; and prepend a single zero octet only when the first remaining octet has its top bit set. The result is positive, minimal, and carries every bit it was given. An agent certificate asserting cA = TRUE is a certificate entitled to issue further certificates. Such an agent can create children without presenting a request to the Template Registry CA, which removes both checks required by Section 10.1 from the spawn path entirely. No signature is invalid in that scenario and no chain fails to verify; the containment described in Section 8 is simply never consulted. This is the reason the constraint is stated normatively here rather than left to the general RFC 5280 profile. These requirements are necessary and not sufficient. A certificate satisfying all of them establishes identity only; it carries no authorization. See Section 19.6. Trujillo Expires 8 March 2027 [Page 12] Internet-Draft A2A Trust September 2026 7.2. Binding Identity to the Certificate An agent has exactly one identity, expressed as a UUID in the canonical lowercase textual form defined in [RFC9562]. A relying party MUST refuse a certificate whose subject common name is absent, is not a well-formed UUID in that form, or does not match the agent identifier the presenting party claims. Uppercase hexadecimal MUST be refused rather than case-folded: the identifier is compared byte- for-byte in several places, and an implementation that folds in one of them and not another will accept a document another implementation refuses. This document does not constrain which UUID version is used. Implementations SHOULD use version 4 where the time an agent was created should not be inferable from its identifier, and MAY use version 7 where time-ordered identifiers are wanted and that disclosure is acceptable. A version 7 identifier embeds a millisecond timestamp, and an agent identifier travels to places its template does not -- audit records, policy references, diagnostic messages -- so the disclosure is wider than the certificate's own notBefore field. Where a chain document restates that identifier alongside the certificate, every restatement MUST be identical to the subject common name, and a relying party MUST refuse the document if any two disagree. An implementation MUST NOT treat one restatement as authoritative and the others as advisory. This requirement exists because a restated identifier that no signature covers is an unsigned claim sitting next to a signed one. Without this rule a chain could name one agent in the position a relying party reads and present a certificate issued to a different agent, and both artifacts would validate on their own terms. 7.3. Certificate Signing Request Flow Trujillo Expires 8 March 2027 [Page 13] Internet-Draft A2A Trust September 2026 Template Author | defines template (scopes, spawn rules, TTL, owner) v Conformance gate (Section 9.1) | every REQUIRED field present and non-null v Dual attestation (Section 9.2) | Owner signs; Policy Authority countersigns | the same JCS octets v CSR carrying the attested template v Template Registry CA (Section 9.3) | re-applies the gate, re-verifies both signatures | signs the template certificate v Signed Agent Template (registered) | v Orchestrator spawns agent from signed template (Section 10) | agent receives a certificate the CA issues from it | CA chain proves provenance v Resource validates certificate chain: - certificate issued by a trusted Template Registry CA? - Agent Template extension present and well-formed? - scope within bounds? - ALLOW or DENY Figure 3 7.4. Certificate Chain Structure Trujillo Expires 8 March 2027 [Page 14] Internet-Draft A2A Trust September 2026 Template Registry CA (root of trust) | | issues BOTH certificates (Section 9.3) | +--> Orchestrator Agent Certificate | Subject CN: 9f3c... (a UUID, Section 7.2) | Issuer: Template Registry CA | Agent Template extension (Section 8.2): | subject: 9f3c... (equals Subject CN, 9.3) | owner, org_id | permitted_operations: [spawn] | allowed_scopes: [read:data, write:data] | can_spawn: [2b7e...], max_children: 1 | policy_ref, ttl_seconds: 3600 | +--> Child Agent Certificate Subject CN: 2b7e... (a UUID) Issuer: Template Registry CA Agent Template extension: subject: 2b7e... allowed_scopes: [read:data] (subset, 10.3) ttl_seconds: 900 (shorter, SHOULD) Agent Spawn extension (Section 10.5): parent_agent_id: 9f3c... spawned_at, spawn_nonce grant_id (only when spawned under a grant, 13.2) An agent certificate never issues a certificate (Section 7.1). The parent-child link is recorded in the child's Agent Spawn extension; the chain of authority runs through the CA. Figure 4 8. Template Structure 8.1. Static Fields The following fields MUST be present in every agent template certificate and MUST NOT be modified without full re-certification: Trujillo Expires 8 March 2027 [Page 15] Internet-Draft A2A Trust September 2026 +=====================+==========+============================+ | Field | Required | Description | +=====================+==========+============================+ | Subject | REQUIRED | Unique template identifier | +---------------------+----------+----------------------------+ | Owner | REQUIRED | Verified identity of | | | | template owner | +---------------------+----------+----------------------------+ | OrgID | REQUIRED | CA-validated organization | | | | identifier | +---------------------+----------+----------------------------+ | PermittedOperations | REQUIRED | Operations this agent may | | | | perform | +---------------------+----------+----------------------------+ | AllowedScopes | REQUIRED | Maximum scopes this agent | | | | may hold | +---------------------+----------+----------------------------+ | CanSpawn | REQUIRED | Whitelist of permitted | | | | child templates | +---------------------+----------+----------------------------+ | MaxChildren | REQUIRED | Maximum concurrent child | | | | agents | +---------------------+----------+----------------------------+ | PolicyRef | REQUIRED | Pointer to dynamic policy | | | | store | +---------------------+----------+----------------------------+ | TTL | REQUIRED | Maximum agent lifetime | +---------------------+----------+----------------------------+ Table 4 This document defines one value of PermittedOperations: spawn, which an agent MUST hold to invoke Section 10. Any other value, including those shown in examples, is defined by the deployment and carries no meaning under this specification. A template whose CanSpawn is non- empty while its PermittedOperations omits spawn describes an agent permitted to spawn specific children and not permitted to spawn; the conformance gate of Section 9.1 SHOULD refuse it, and a Registry MUST refuse a spawn request from it. Trujillo Expires 8 March 2027 [Page 16] Internet-Draft A2A Trust September 2026 A template defines exactly one agent (Section 4), so each entry of CanSpawn names a child that can exist at most once at a time, and MaxChildren counts named children rather than instances of one. MaxChildren MUST NOT exceed the number of entries in CanSpawn. The conformance gate of Section 9.1 MUST refuse a template that violates this, and a relying party MUST refuse a certificate whose extension does. A cap above the number of children a template can name is a cap on nothing, and a validator reading it would count toward a limit that can never be reached. The certificate's issuer is not a template field. It is set by the Template Registry CA at issuance (Section 9.3) and read from the certificate (Section 8.2); a template carries no member for it. 8.2. Encoding of Static Fields The fields in Section 8.1 MUST be carried in a single X.509 certificate extension, identified by the object identifier 2.25.318754453516410815925104555075461256891 and referred to in this document as the Agent Template extension. The extension MUST be marked critical. A validator that does not implement this specification therefore refuses the certificate, as [RFC5280] requires of any unrecognized critical extension, rather than accepting it as an ordinary client certificate and granting whatever its issuer's chain would grant. The certificate is unusable except by a party that understands what it says, which is the fail-closed outcome Section 15.1 requires; an agent certificate has no legitimate use outside this specification. The extnValue MUST be a DER OCTET STRING whose contents are the UTF-8 encoding of a JSON object, serialized as required by Section 3. A relying party MUST refuse a certificate whose Agent Template extension is not valid JCS, and MUST NOT attempt to repair or re- canonicalize it. The JSON object MUST carry exactly the following members, all of which are REQUIRED. Wire names are as given in Table 3. A relying party MUST refuse a certificate whose Agent Template extension omits any member, carries a member not listed here, or carries a member whose type differs from the type given. Trujillo Expires 8 March 2027 [Page 17] Internet-Draft A2A Trust September 2026 +======================+=================+ | Member | Type | +======================+=================+ | subject | string | +----------------------+-----------------+ | owner | string | +----------------------+-----------------+ | org_id | string | +----------------------+-----------------+ | permitted_operations | array of string | +----------------------+-----------------+ | allowed_scopes | array of string | +----------------------+-----------------+ | can_spawn | array of string | +----------------------+-----------------+ | max_children | integer | +----------------------+-----------------+ | policy_ref | string | +----------------------+-----------------+ | ttl_seconds | integer | +----------------------+-----------------+ Table 5: Agent Template Extension Members The ttl_seconds member states a duration in seconds; the display name TTL in Section 8.1 does not carry a unit, and a duration whose unit is inferred is a duration two implementations will infer differently. The certificate's issuer has no member in this extension. X.509 already carries the issuer, and a second copy inside an extension the issuer signs could disagree with the copy the relying party validated the signature against. A relying party MUST take the issuer from the certificate. A certificate MUST NOT carry more than one Agent Template extension, and a relying party MUST refuse a certificate carrying two rather than choosing between them. The duplicate member rule of Section 3 applies, and is a requirement on the parser used to read the extension. A relying party MUST impose a limit on the size of the extension before parsing it, and MUST refuse an extension exceeding that limit rather than attempting a partial parse. The limit is 16384 octets of extnValue for the Agent Template extension and 1024 octets for the Agent Spawn extension of Section 10.5. The first holds two hundred scopes at the maximum length of Section 10.3, which is more than any template this document contemplates; the second holds every member of a fixed-shape object with room to spare; and neither is large enough Trujillo Expires 8 March 2027 [Page 18] Internet-Draft A2A Trust September 2026 to be worth handing to a parser unverified. The extension arrives inside a certificate presented by the party whose authority it describes; it is attacker-controlled input up to the point the issuer's signature has been verified, and that signature covers whether the bytes were issued, not whether they are safe to parse. Implementations SHOULD verify the certificate signature before parsing the extension, so that malformed input from an unsigned certificate is discarded without being decoded at all. Placing these fields in the certificate rather than in a document accompanying it is deliberate. Section 8.1 requires that they not change without re-certification. A field carried outside the certificate is signed by whoever assembled the document, not by the Template Registry CA, so an agent could present a valid certificate beside a template granting authority the CA never issued. Carrying them inside the certificate makes the immutability requirement a property of the artifact rather than a rule an implementation is asked to remember. 8.3. Dynamic Policy Bounds Dynamic policies MUST be bounded by the static template fields. A dynamic policy MUST NOT grant scopes beyond AllowedScopes. A dynamic policy MUST NOT add spawn targets beyond CanSpawn. A relying party MUST evaluate these bounds itself, on every validation, against the static fields of the template certificate naming the subject the policy governs. This evaluation MUST be independent of signature validity -- a bounds violation is refused whether or not the signatures verify -- and it is performed after signature verification, in the order given by Section 11.7, so that a refusal under this section reports an authentic document whose content is not permitted. A policy exceeding the bounds MUST be refused before it is applied, however many valid signatures it carries. The signatures required by Section 11.3 and the bounds required here answer different questions. The signatures establish who authorized a change. They do not, and cannot, establish that the change was within the ceiling the template set, because the ceiling is stated in a certificate that no signature over the policy covers. An implementation that treats a valid dual signature as sufficient authority to apply a policy has removed the only mechanism bounding what a policy may grant. Trujillo Expires 8 March 2027 [Page 19] Internet-Draft A2A Trust September 2026 Refusal under this section is a distinct condition from a signature failure, and implementations SHOULD report it distinctly: the document is authentic and its content is not permitted. Reporting it as a signature failure misdirects the operator to the wrong lane of Section 11.1. 9. Template Authoring and Attestation A template is authored before any certificate is issued against it. This section specifies the checks that MUST pass before a Template Registry CA issues a certificate carrying the fields of Section 8.1. 9.1. Conformance Gate Every field marked REQUIRED in Section 8.1 MUST be present and non- null before a template is signed. A template missing any REQUIRED field is non-conforming and MUST be refused, both at signing and again at issuance. An implementation MUST NOT sign a non-conforming template, and MUST NOT issue a certificate against one by omitting the corresponding member from the Agent Template extension. The gate is applied twice deliberately. A template that was conforming when signed can be edited afterwards, and an issuance path that trusts the signature without re-checking conformance will issue a certificate whose extension is missing a member the relying party requires. 9.2. Dual Attestation A template MUST carry two signatures before it is eligible for issuance: one from the template Owner and one from the Policy Authority. Both signatures MUST be computed over the same octet string, as required by Section 3.1, being the JCS serialization of the template restricted to the members of Table 5. A relying party MUST verify both, and MUST refuse the template if either is absent or does not verify. Signature verification MUST occur after the conformance gate of Section 9.1, not before. A signature over an incomplete body is a valid signature over an incomplete body. Every member that becomes part of the Agent Template extension MUST be inside the signed body. A member carried into a certificate without having been covered by both signatures has entered the certificate without the approval the two signatures exist to record. Trujillo Expires 8 March 2027 [Page 20] Internet-Draft A2A Trust September 2026 Both signatures MUST use the algorithm that Table 2 assigns to the signer's key type, over a key meeting the strength floor of Section 7.1. The requirement is stated by reference rather than restated, because two lists of acceptable algorithms in one document will eventually disagree, and the weaker of the two becomes the one an implementation follows. The Owner and the Policy Authority each hold a certificate conforming to Section 7.1, issued by the Template Registry CA or by a CA the relying party trusts for that purpose. A relying party MUST validate that certificate to a trust anchor it holds before verifying any signature with its key, and MUST refuse a signature whose certificate does not validate: a signature that verifies under an untrusted key establishes nothing. The subject common name of the Owner certificate MUST equal the template's owner member; that equality is what binds the string in owner to a key. The Policy Authority certificate is a trust decision the relying party configures, one per Registry. 9.3. Issuance On issuance the Template Registry CA MUST re-apply the conformance gate, MUST re-verify both signatures, and MUST copy the signed members into the Agent Template extension of Section 8.2 without alteration. The CA MUST set the certificate subject common name to the value of the template's subject member, which MUST satisfy Section 7.2, and MUST set the issuer to its own name. The template carries no issuer member, and the CA MUST NOT take the issuer from the template. A relying party MUST refuse a certificate whose subject common name differs from the subject member of its Agent Template extension. The CA MUST set the certificate's notAfter to no later than its notBefore plus the template's ttl_seconds, so that the TTL of Section 8.1 is enforced by ordinary certificate path validation and not only by a relying party that reads the extension. A relying party MUST refuse a certificate whose notAfter minus notBefore, in seconds, exceeds its ttl_seconds: a certificate that outlives its own stated lifetime was not issued as this section requires. ttl_seconds MUST NOT exceed 604800 (seven days), and SHOULD NOT exceed 86400 (one day). A relying party MUST refuse a certificate whose ttl_seconds exceeds the maximum. An agent is ephemeral by the definition in Section 4; its certificate's lifetime is the longest an attacker holding its key can act if revocation is slow to propagate, and Section 15.1 can only refuse a certificate a relying party knows to be revoked. A short lifetime bounds that window without depending on revocation reaching every relying party. Trujillo Expires 8 March 2027 [Page 21] Internet-Draft A2A Trust September 2026 10. Spawn Chain Validation 10.1. Two-Check Spawn Rule Every spawn MUST pass two independent checks. Either check failing MUST result in spawn denial with no fallback. The Template Registry performs both checks, as Section 10.2 specifies. That section lists the individual conditions in the order they are evaluated; this section states which check each condition belongs to, and an implementation MUST evaluate every condition of both. Check 1 -- Static (from the spawning agent's certificate): The spawning agent's PermittedOperations MUST include spawn, the requested child template MUST appear in the spawning agent's CanSpawn list, and the requested scopes MUST be a subset of the spawning agent's AllowedScopes (Section 10.3). All three are read from the Agent Template extension of the spawning agent's certificate, never from a document the agent supplies. These are steps 1 and 4 of Section 10.2. Check 2 -- Dynamic (Registry live lookup): The requested child template MUST be currently registered, CA-signed, not self-signed, not present in the current CRL, not DISABLED under Section 12.4, and owned either by the spawning agent's organization or by an organization that has issued a grant under Section 13 naming the spawning agent's organization as Grantee. The child template MUST also appear in the SpawnTargets of the dynamic policy currently in force for the spawning agent (Section 11.4), which the Registry retrieves through the PolicyRef of the spawning agent's certificate and never accepts from the agent; a policy with no SpawnTargets grants none, and an agent with no policy in force may not spawn. Finally the spawning agent's live child count MUST be below its MaxChildren. These are steps 2, 3 and 5 of Section 10.2. Rationale: CanSpawn alone is insufficient because the certificate may be stale and a template may have been revoked since issuance. Registry lookup alone is insufficient because any party could forge a request claiming any template. The policy condition is what gives the fast lane of Section 11.1 authority over spawning: CanSpawn is the ceiling the certificate sets, SpawnTargets is what the Owner has currently authorized within it, and a spawn target can therefore be withdrawn by a policy change without re-certification. Both checks MUST pass. 10.2. Spawn Validation Sequence Trujillo Expires 8 March 2027 [Page 22] Internet-Draft A2A Trust September 2026 1. CanSpawn check -- spawn in PermittedOperations, and child template in CanSpawn list? NO --> DENY, audit log YES --> continue 2. Registry check -- child template registered, CA-signed, not revoked, not DISABLED, and owned by the spawning agent's organization or granted to it? NO --> DENY, audit log YES --> continue 3. Policy check -- child template in the SpawnTargets of the policy in force for the spawning agent? NO --> DENY, audit log YES --> continue 4. Scope check -- requested scope subset of parent scopes? NO --> DENY, audit log YES --> continue 5. MaxChildren check -- current children < MaxChildren, and no live certificate for the child template already? NO --> DENY, audit log YES --> spawn approved 6. Template Registry CA issues the child certificate with: - parent identity embedded (delegation chain) - scope equal to requested scope (not exceeding parent) - spawn timestamp and nonce (replay prevention) - grant identifier, when spawned under a grant - audit log entry written Figure 5 The count compared against MaxChildren in step 5 is held by the Template Registry, which is the only party that observes every spawn under a template. The Registry MUST perform that comparison as part of Check 2 of Section 10.1, atomically with recording the new child, so that two concurrent spawn requests cannot both observe a count one below the limit and both succeed. The second condition of step 5 follows from Section 12.1: a template defines one agent, one identity never holds two valid certificates, and the Registry MUST therefore refuse to spawn a child whose template already has an unexpired, unrevoked certificate. A relying party validating a chain document counts only the children that document names, and MUST refuse a document in which that count exceeds the parent's MaxChildren; that is a consistency check on the document, not the enforcement of the cap, and an implementation MUST NOT present it as such. Trujillo Expires 8 March 2027 [Page 23] Internet-Draft A2A Trust September 2026 The Template Registry CA performs steps 1 through 5 and issues the certificate in step 6. The spawning agent presents a spawn request -- the child template's subject, the requested scopes, a timestamp, and a nonce per Section 19.2 -- and receives the issued certificate; it signs nothing, because Section 7.1 forbids an agent certificate from issuing. Steps 1 and 4 are evaluated against the spawning agent's own Agent Template extension, which the Registry reads from the certificate it presented. Step 3 is evaluated against the policy in force for the spawning agent, which the Registry retrieves through the PolicyRef of that extension; a policy the agent supplies with its request MUST NOT be consulted. If the policy store cannot be reached, or no policy is in force, the request is refused under Section 15.1. 10.3. Scope Constraint A child agent's AllowedScopes MUST be a subset of the parent agent's AllowedScopes: every scope granted to the child MUST also be held by the parent. A child MUST NOT be granted any scope the parent does not itself hold; scope escalation across agent hops is explicitly prohibited. Equality is permitted -- a child MAY be granted the same scope set as its parent, or fewer. Example: Parent has: read:data, write:data Child gets: read:data -- valid Child gets: read:data, write:data -- valid (same as parent) Child gets: admin:data -- MUST be rejected Figure 6 A scope is an opaque token. Two scopes are the same scope when their octets are identical, and a relying party MUST NOT apply case folding, Unicode normalization, prefix matching, wildcard expansion, or any hierarchy: write:data does not imply read:data, and admin:* names nothing. A scope MUST be between 1 and 64 octets, each from the set of lowercase ASCII letters, ASCII digits, colon, underscore, and hyphen. A relying party MUST refuse a document carrying a scope outside that syntax; the syntax is constrained so that byte comparison is also visual comparison, and a confusable character cannot name a scope that looks like another. What a scope grants access to -- a secrets store, a data set, a tool -- is resource-layer authorization and is outside this document, as the Abstract states. This document bounds which scopes an agent may hold and how that bound narrows across a spawn; it does not define what any scope means. A deployment that needs to express "this agent Trujillo Expires 8 March 2027 [Page 24] Internet-Draft A2A Trust September 2026 may read vault A" does so with a scope such as secrets:vault-a:read, carried in allowed_scopes, bounded by the parent's allowed_scopes, and interpreted by the resource that owns vault A. The registry of Section 17.3 exists so that such names can eventually mean the same thing across organizations. A collection of scopes is a set. The order in which its members appear is not significant to any comparison in this document, and a collection carrying the same scope twice is malformed and MUST be refused. The subset test above is therefore set containment, and two conforming implementations reach the same answer for the same two collections regardless of ordering. Order is significant only to serialization: [RFC8785] preserves array order, so the octets a signature covers depend on it. An implementation that reorders a collection before verifying it has changed those octets, and the signature fails; reordering is therefore not a normalization step. Comparison is performed on the parsed set, verification on the octets as received. A request for no scopes MUST be refused. The empty set is a subset of every set, so an empty request satisfies the containment test vacuously while declaring no intent for the test to bound. A child's ttl_seconds SHOULD NOT exceed its parent's. A delegation that outlives its delegator holds authority derived from an agent that no longer exists; the parent's certificate may be renewed, but a child sized to outlast it was sized on the assumption that it would not need to be. 10.4. Audit Requirements Every spawn event, accepted or refused, MUST be recorded as an audit log entry: a JSON object carrying exactly the following members, subject to the presence rules the table states, serialized as Section 3 requires and hashed as Section 19.7 requires. The entry has no display names; wire names are given directly. +===================+========+==================================+ | Member | Type | Content | +===================+========+==================================+ | spawning_agent_id | string | Identifier of the spawning | | | | agent, in the form of | | | | Section 7.2 | +-------------------+--------+----------------------------------+ | child_template_id | string | Subject of the requested child | | | | template, in the same form | +-------------------+--------+----------------------------------+ | requested_scopes | array | The scopes the request asked for | Trujillo Expires 8 March 2027 [Page 25] Internet-Draft A2A Trust September 2026 | | of | | | | string | | +-------------------+--------+----------------------------------+ | granted_scopes | array | The scopes issued; empty when | | | of | outcome is DENIED | | | string | | +-------------------+--------+----------------------------------+ | spawn_nonce | string | The nonce of the request, per | | | | Section 19.2 | +-------------------+--------+----------------------------------+ | grant_id | string | The GrantID of Section 13.2 when | | | | the spawn was requested under a | | | | grant; MUST be absent otherwise | +-------------------+--------+----------------------------------+ | timestamp | string | The instant the Registry | | | | recorded the outcome, per | | | | [RFC3339], in UTC | +-------------------+--------+----------------------------------+ | outcome | string | ALLOWED or DENIED, exactly | +-------------------+--------+----------------------------------+ | reason | string | The step of Section 10.2 that | | | | refused the request, and why; | | | | REQUIRED when outcome is DENIED, | | | | MUST be absent otherwise | +-------------------+--------+----------------------------------+ | previous_hash | string | The entry_hash of the preceding | | | | entry, lowercase hexadecimal; | | | | sixty-four zero digits for the | | | | first entry of a log | +-------------------+--------+----------------------------------+ | entry_hash | string | SHA-256 over the canonical form | | | | of every other member of this | | | | entry, lowercase hexadecimal, | | | | per Section 19.7 | +-------------------+--------+----------------------------------+ Table 6: Audit Log Entry Members A refused request is recorded for the same reason an accepted one is: a sequence of refusals is the evidence of an attempt, and a log that records only successes cannot show one. Trujillo Expires 8 March 2027 [Page 26] Internet-Draft A2A Trust September 2026 10.5. Encoding of Spawn Provenance Step 5 of Section 10.2 issues a child certificate carrying its parent's identity, the time of the spawn, and the nonce of the request that produced it. These MUST be carried in a single X.509 extension, marked critical for the reason given in Section 8.2, identified by the object identifier 2.25.316124730704531463413455892107752909312 and referred to in this document as the Agent Spawn extension. It is encoded exactly as the Agent Template extension of Section 8.2: a DER OCTET STRING containing the UTF-8 JCS serialization of a JSON object, subject to the same rules on criticality, duplicate members, duplicate extensions, size limits, and parse ordering. +=================+========+======================================+ | Member | Type | Content | +=================+========+======================================+ | parent_agent_id | string | The parent's identifier, in the form | | | | required by Section 7.2 | +-----------------+--------+--------------------------------------+ | spawned_at | string | The instant of issuance, per | | | | [RFC3339], in UTC | +-----------------+--------+--------------------------------------+ | spawn_nonce | string | The nonce of the spawn request, per | | | | Section 19.2 | +-----------------+--------+--------------------------------------+ | grant_id | string | The GrantID of the grant under which | | | | the spawn was authorized | | | | (Section 13.2); REQUIRED when the | | | | child template is owned by an | | | | organization other than the spawning | | | | agent's, MUST be absent otherwise | +-----------------+--------+--------------------------------------+ Table 7: Agent Spawn Extension Members parent_agent_id, spawned_at and spawn_nonce are REQUIRED when the extension is present; grant_id is present exactly when the spawn was cross-organizational, and a relying party MUST refuse a certificate that carries it for a child owned by the parent's own organization or omits it for one that is not. A certificate for an agent that has a parent MUST carry the extension; a certificate for an agent that has none -- a root orchestrator -- MUST NOT. A relying party validating a chain MUST refuse a certificate whose parent_agent_id names no agent in the chain, MUST refuse one whose parent_agent_id differs from the parent the chain document names for it, and MUST refuse a root whose certificate carries the extension. Trujillo Expires 8 March 2027 [Page 27] Internet-Draft A2A Trust September 2026 This is what makes a spawn chain cryptographically traceable rather than merely asserted. A parent identifier carried only in a chain document is an unsigned claim beside a signed certificate: a child could name any parent it liked, and the containment of Section 10.3 would be evaluated against whichever parent it chose. Carrying the link in the certificate means the CA that issued the child attested to which agent spawned it, and that attestation is what the scope and spawn checks are evaluated against. The parent's Agent Template extension, not the child's Agent Spawn extension, is where the child's authority is bounded. The Agent Spawn extension says who the parent is; the parent's certificate says what the parent may delegate. The absence of the Agent Spawn extension asserts that no agent spawned this one; it does not exempt the certificate from anything. A root is legitimate for the same reason any agent certificate is: it was issued by the Template Registry CA from a template attested under Section 9, and it chains to that CA under Section 7.1. No party can declare itself a root, because no party other than the CA can issue a certificate that validates, and the CA issues only from attested templates. A relying party verifies a root exactly as it verifies any other agent certificate. spawned_at and spawn_nonce record the request the Registry accepted. The freshness window of Section 19.2 applies to that request, at the Registry, at the time it is made. A relying party validating an issued certificate later MUST NOT apply the window to spawned_at: a certificate an hour old is as valid as one a second old, and its currency is governed by its validity period and its revocation state, not by when it was requested. A relying party MUST, however, refuse a chain in which two certificates carry the same spawn_nonce. That is a consistency check on the document, in the sense Section 10.2 gives the term: what makes a nonce unique across every chain the Registry ever issues is that the Registry accepts each nonce once, under Section 19.2, and a relying party holding one chain cannot observe another. An implementation MUST NOT present the document- local check as the enforcement of uniqueness. grant_id is what makes Section 13.4 enforceable. A grant can be revoked by its Grantor alone, and every certificate issued under it must then become untrusted; without a member naming the grant, nothing identifies those certificates. With it, the Registry that issued them can revoke them, and a relying party in either organization learns of it through the revocation state the certificate already points to. Trujillo Expires 8 March 2027 [Page 28] Internet-Draft A2A Trust September 2026 11. Dynamic Policy Governance 11.1. Two-Lane Model Template certificate (static): WHO the agent is and WHO it can spawn. Changes require full re-certification. Dynamic policy (fast lane): WHAT the agent can do within the bounds of the template certificate. Changes require dual signature (Section 11.3). Dynamic policies MUST NOT exceed the bounds defined in the static template certificate. 11.2. Ownership Template ownership MUST be established at certificate signing time and embedded in the Owner and OrgID fields. Only the verified owner of the organization that signed the template MAY submit policy changes. Verified means holding the private key of the Owner certificate of Section 9.2, whose subject common name equals the template's Owner field; no other form of verification is defined by this document. 11.3. Dual Signature Requirement Every policy change MUST be signed by two independent parties: 1. Owner -- proves the right to change the policy. 2. Policy Authority -- proves the policy passed automated validation gates. Neither signature alone is sufficient. Both MUST be present and valid for a policy to be accepted. Owner key + Policy Authority key = policy accepted ^ ^ who owns it passed the gates Figure 7 11.4. Dynamic Policy Document Structure A dynamic policy document MUST contain the following fields. This is the complete set; a document containing any other field MUST be refused, since an unrecognized field is either meaningless or an attempt to convey authority the profile does not define. Trujillo Expires 8 March 2027 [Page 29] Internet-Draft A2A Trust September 2026 +==============+=========+==========+==============================+ | Field | Type | Required | Description | +==============+=========+==========+==============================+ | Subject | string | REQUIRED | Identifier of the agent this | | | | | policy governs; MUST match | | | | | the Subject of the template | | | | | certificate | +--------------+---------+----------+------------------------------+ | Owner | string | REQUIRED | Submitting owner; MUST match | | | | | Owner in the template | | | | | certificate | +--------------+---------+----------+------------------------------+ | OrgID | string | REQUIRED | Submitting organization; | | | | | MUST match OrgID in the | | | | | template certificate | +--------------+---------+----------+------------------------------+ | Scopes | array | REQUIRED | Scopes granted by this | | | of | | policy; bounded by | | | string | | AllowedScopes | +--------------+---------+----------+------------------------------+ | SpawnTargets | array | OPTIONAL | Spawn targets granted by | | | of | | this policy, each a template | | | string | | Subject in the form of | | | | | Section 7.2; bounded by | | | | | CanSpawn. Absent means none | | | | | are granted, and a spawn | | | | | request is then refused at | | | | | step 3 of Section 10.2 | +--------------+---------+----------+------------------------------+ | Version | integer | REQUIRED | Monotonically increasing | | | | | integer, scoped to Subject | +--------------+---------+----------+------------------------------+ | IssuedAt | string | REQUIRED | Timestamp of issuance, per | | | | | [RFC3339] | +--------------+---------+----------+------------------------------+ | NotAfter | string | OPTIONAL | Expiry of this policy, per | | | | | [RFC3339]; MUST NOT be later | | | | | than the notAfter of the | | | | | certificate the policy | | | | | governs. Absent means equal | | | | | to it | +--------------+---------+----------+------------------------------+ Table 8: Dynamic Policy Document Fields Version is scoped to the Subject, not global. A relying party MUST refuse a policy whose Version is not strictly greater than the Version of the policy currently in force for that Subject. Trujillo Expires 8 March 2027 [Page 30] Internet-Draft A2A Trust September 2026 A policy is never valid beyond the notAfter of the certificate it governs, whether or not NotAfter is present. NotAfter can only shorten that period. A relying party MUST treat an absent NotAfter as equal to the certificate's notAfter, MUST refuse a policy whose NotAfter is later than it, and MUST refuse a policy presented after either has passed. 11.5. Canonicalization Signatures and hashes defined by this document are computed over bytes, so the mapping from a policy document to those bytes MUST be deterministic and identical across implementations. Wherever this document requires a canonical form -- of a policy document, of any field subset thereof, or of an audit log entry -- that canonical form MUST be the JSON Canonicalization Scheme (JCS) serialization defined in [RFC8785]. A single canonical form is specified for all of them deliberately: an implementation carrying two serializations will eventually apply the wrong one, and the resulting failure presents as a signature or integrity error with no indication that serialization was the cause. JCS is specified rather than described here because a bespoke serialization would require this document to define property ordering, string escaping, and number formatting correctly and completely, and any error in that definition surfaces to implementers as a signature failure that appears to be a cryptographic fault. Serializations that differ only in whitespace, key order, or the escaping of non-ASCII characters produce different bytes and therefore different signatures; implementers MUST NOT assume a language's default JSON encoder produces the canonical form, as most do not. 11.6. Signature and Hash Coverage Both signatures required by Section 11.3 are computed over the preimage defined in Section 3.1: the canonical form (Section 11.5) of body. Because Section 11.4 makes its table the complete content of body, every field in that table is inside the preimage and none is excluded from either signature. This section and Section 3.1 describe the same octets. In particular, Version MUST be inside the signed preimage. Version exists to prevent replay, and it cannot serve that purpose while it remains modifiable without invalidating a signature: an attacker holding no key can otherwise take a superseded but validly signed policy, increment its Version, and present it as current. Both signatures verify, the content hash matches, and the version reads as Trujillo Expires 8 March 2027 [Page 31] Internet-Draft A2A Trust September 2026 current. The same reasoning applies to Subject: a signature that does not bind the policy to the agent it governs permits a policy issued for one agent to be presented for another. The content hash is a member of the envelope of a dynamic policy document only. It is REQUIRED there, because step 4 of Section 11.7 stores the policy and step 5 re-reads it, and a stored document wants an integrity value that is cheaper to check than two signatures; it MUST be absent from the envelope of a template or a grant, which are verified on presentation and whose signatures already cover the same octets. The content hash MUST be SHA-256, or a stronger digest, computed over the same canonical form and the same field set as the signatures. The hash field itself is stored alongside the policy document and MUST NOT be included in its own preimage. The content hash is a derived value: a relying party MUST recompute it from body and refuse the document on a mismatch, and MUST NOT use the envelope's content_hash as an input to any decision. A modified content_hash therefore causes a refusal and nothing else; it is not a value a signature needs to protect, because the signature already covers everything the hash summarizes. The signatures and the content hash are carried in the envelope of Section 3.1, outside the policy document they attest to. A relying party MUST refuse a policy document that carries any of them as a policy field: they are not in Section 11.4, and a value inside body would be inside its own preimage. 11.7. Policy Change Sequence Trujillo Expires 8 March 2027 [Page 32] Internet-Draft A2A Trust September 2026 1. Identity and ownership verification - requester matches Owner in template certificate? - requester OrgID matches certificate OrgID? NO --> rejected, audit logged 2. Automated gate (policy engine): - scope within AllowedScopes? - spawn targets within CanSpawn? - no conflicts with active policies? ANY FAIL --> rejected 3. Dual signature applied: Owner signs, Policy Authority countersigns 4. Policy stored with dual signature, version, timestamp, and content hash 5. Relying party validates at runtime: - both signatures valid? - version current? (replay prevention) - hash matches? (tamper detection) - policy within template certificate bounds? ANY FAIL --> DENY, audit logged Figure 8 11.8. Threat Coverage +========================+===================+===================+ | Scenario | Single Sig Gap | Dual Sig Fix | +========================+===================+===================+ | Rogue Policy Authority | Pushes bad policy | Owner key missing | +------------------------+-------------------+-------------------+ | Rogue owner | Bypasses | PA won't | | | automated gates | countersign | +------------------------+-------------------+-------------------+ | Compromised owner key | Attacker modifies | Automated gates | | | | enforced | +------------------------+-------------------+-------------------+ | Compromised Policy | Pushes bad policy | Owner key missing | | Auth | | | +------------------------+-------------------+-------------------+ Table 9 The table above concerns the dual signature. The following concerns the encodings this document specifies, and the attack each one closes. Trujillo Expires 8 March 2027 [Page 33] Internet-Draft A2A Trust September 2026 +==============+============================+=======================+ | Scenario | Without the encoding | With it | +==============+============================+=======================+ | Replayed | An Owner signature | Both signatures cover | | Owner | over anything other | the same body | | signature | than the policy body | (Section 3.1); a | | | verifies for every | signature is specific | | | later policy on that | to one policy | | | agent; a rogue Policy | | | | Authority reuses it | | +--------------+----------------------------+-----------------------+ | Replayed | A superseded but | Version is inside the | | policy | validly signed policy | preimage and must | | | is presented as | exceed the version in | | | current | force (Section 11.4) | +--------------+----------------------------+-----------------------+ | Swapped | A valid certificate | Static fields live in | | template | is presented beside a | the certificate | | | template granting | (Section 8.2); there | | | authority the CA | is no separate | | | never issued | template to swap | +--------------+----------------------------+-----------------------+ | Forged | A child names | The parent link is in | | parent | whichever parent | the child's | | | gives it the widest | certificate, attested | | | scope; containment is | by the CA | | | evaluated against | (Section 10.5) | | | that parent | | +--------------+----------------------------+-----------------------+ | Mismatched | A chain names one | Every restatement | | identity | agent and presents a | must equal the | | | certificate issued to | subject CN | | | another; both | (Section 7.2) | | | validate on their own | | | | terms | | +--------------+----------------------------+-----------------------+ | Silent | Two parsers keep | Duplicate detection | | parser | different duplicates | is a parser | | disagreement | of a key and both | requirement | | | report success | (Section 3) | +--------------+----------------------------+-----------------------+ | Unlocatable | Revocation must be | cRLDistributionPoints | | revocation | consulted but the | or OCSP is required | | | certificate does not | (Section 14.4) | | | say where | | +--------------+----------------------------+-----------------------+ | Spawn under | A grant is revoked | grant_id in the Agent | | a revoked | and nothing | Spawn extension; the | Trujillo Expires 8 March 2027 [Page 34] Internet-Draft A2A Trust September 2026 | grant | identifies the | issuing Registry | | | certificates issued | revokes them | | | under it | (Section 13.4) | +--------------+----------------------------+-----------------------+ | Spawn the | A policy grants no | SpawnTargets is a | | policy | spawn targets and the | step of the spawn | | withdrew | agent spawns | sequence | | | everything its | (Section 10.2) | | | certificate's | | | | CanSpawn allows | | +--------------+----------------------------+-----------------------+ Table 10: Encoding Threat Coverage 12. Template Versioning 12.1. Full Re-Verification Required A new template version MUST undergo full re-verification from scratch. Trust MUST NOT be inherited from a previous version. Rationale: inheriting trust from v1 would allow a compromised v1 certificate to bootstrap trust for v2. A new version keeps the template's Subject and receives a new certificate. The Registry MUST revoke the prior certificate when it issues the new one, so that one identity never has two valid certificates; a relying party that encounters two unrevoked certificates for one Subject MUST refuse both. 12.2. Versioning Principle Everything on the old template chain continues to work unchanged as long as the certificate is valid. New connections and functionality are opt-in -- only available after the new template chain is fully verified and explicitly adopted. 12.3. Non-Inheritance Rules The following MUST NOT be inherited from a previous version: * Trust chain * Cross-organizational grants * CanSpawn list * Dynamic policies Trujillo Expires 8 March 2027 [Page 35] Internet-Draft A2A Trust September 2026 12.4. Template Lifecycle ACTIVE: Template is trusted. New spawns accepted. DISABLED: No new spawns. Existing agents run to TTL expiry. Reversible. DELETED: Certificate revoked, CRL updated, registry entry removed. Irreversible. Audit log preserved. DISABLED is a Registry state, not a revocation. It is reported by the Registry in Check 2 of Section 10.1 and is not carried in a CRL. Because only the Registry performs spawns, no other party needs to distinguish DISABLED from ACTIVE: a relying party validating an existing agent's certificate consults revocation state as usual, and an agent issued under a template that is later DISABLED remains valid until its TTL or its revocation. Disable SHOULD precede delete. Implementations SHOULD enforce a mandatory waiting period between DISABLED and DELETED. 12.5. Cross-Organizational Grant Re-Issuance Cross-organizational grants MUST be explicitly re-issued for each new template version. Grants MUST NOT automatically roll over on version upgrade. 13. Cross-Organizational Agent Interaction 13.1. Explicit Grant Requirement Cross-organizational agent spawning MUST be explicitly authorized by the resource-owning organization. No implicit trust exists between organizations. 13.2. Grant Structure A cross-organizational grant MUST contain exactly the following fields: Trujillo Expires 8 March 2027 [Page 36] Internet-Draft A2A Trust September 2026 +===============+=========+=======================================+ | Field | Type | Description | +===============+=========+=======================================+ | GrantID | string | Identifier of this grant: a UUID in | | | | the form of Section 7.2, unique among | | | | the grants the Grantor has issued | +---------------+---------+---------------------------------------+ | Grantor | string | OrgID of the resource-owning | | | | organization | +---------------+---------+---------------------------------------+ | Grantee | string | OrgID of the requesting organization | +---------------+---------+---------------------------------------+ | Template | string | Subject of the template granted, in | | | | the form of Section 7.2 | +---------------+---------+---------------------------------------+ | AllowedScopes | array | MUST be a subset of the template's | | | of | AllowedScopes | | | string | | +---------------+---------+---------------------------------------+ | IssuedAt | string | Instant of issuance, per [RFC3339], | | | | in UTC | +---------------+---------+---------------------------------------+ | TTL | integer | Grant validity period in seconds, | | | | counted from IssuedAt | +---------------+---------+---------------------------------------+ | MaxSpawns | integer | Maximum concurrent agents permitted | | | | under this grant | +---------------+---------+---------------------------------------+ Table 11: Cross-Organizational Grant Fields Wire names are given in Table 3. A grant is signed as specified in Section 3.1, by the grantor's Owner and Policy Authority; the signatures are envelope members and are not fields of the grant. A grant expires at IssuedAt plus TTL seconds. A relying party MUST refuse a grant whose expiry has passed, and MUST refuse one whose IssuedAt is later than its own clock by more than the freshness window of Section 19.2. A duration with no stated origin has no expiry two parties can agree on; IssuedAt is the origin. A cross-organizational spawn is evaluated and issued by the Grantor's Registry, which owns the template and the CA that issues against it. That Registry holds the count compared against MaxSpawns and MUST enforce it atomically with recording the spawn, exactly as Section 10.2 requires of MaxChildren. The Grantee's organization performs no part of the issuance and cannot enforce the cap. Trujillo Expires 8 March 2027 [Page 37] Internet-Draft A2A Trust September 2026 13.3. Trust Anchor Options Federated CA: Both organizations trust a shared root CA. Explicit CA trust: Org-B explicitly trusts Org-A's CA. Third-party CA: Both organizations use a public CA. Which option applies is deployment policy. Under each, a relying party in the Grantee organization MUST hold a trust anchor for the Grantor's Template Registry CA and MUST validate the Grantor's Owner and Policy Authority certificates to it, as Section 9.2 requires, before accepting a grant's signatures. A grant whose signatures cannot be validated to a trust anchor the relying party holds MUST be refused. 13.4. Unilateral Revocation The granting organization MAY revoke a cross-organizational grant without the cooperation of the receiving organization. Upon revocation, all agents spawned under the affected grant MUST be treated as untrusted on next validation. The Grantor's Registry issued every such certificate, and each carries the grant's GrantID in its Agent Spawn extension (Section 10.5). On revoking a grant the Registry MUST revoke, under Section 14, every unexpired certificate whose grant_id names it, and MUST refuse further spawn requests under it. A relying party in either organization then learns of the revocation through the revocation state the certificate itself points to (Section 14.4), and needs no channel to the Grantor beyond that. 13.5. Federated Audit Each organization MUST maintain its own independent audit trail. Audit records MUST NOT depend on the other organization's systems. 14. Revocation 14.1. Template Revocation Template revocation MUST be performed by recording the template certificate as revoked in the CA's revocation state -- an X.509 CRL, an OCSP responder, or an equivalent revocation registry consulted on every validation. All agent certificates derived from a revoked template MUST be treated as untrusted on the next revocation check. Trujillo Expires 8 March 2027 [Page 38] Internet-Draft A2A Trust September 2026 14.2. Individual Agent Revocation Individual agents MAY be revoked by explicit certificate revocation or, outside this document, by removal of authorization relationships at the resource layer. 14.3. Automation Requirement Routine revocation (TTL expiry, task completion) MUST be fully automated. Human involvement SHOULD be reserved for incident response and high-impact decisions. 14.4. Locating Revocation State Every certificate issued under this specification, other than a self- signed trust anchor, MUST carry either the cRLDistributionPoints extension or the authorityInfoAccess extension with an id-ad-ocsp accessMethod, both as defined in [RFC5280]. A relying party MUST refuse a certificate carrying neither, because the obligation in Section 14.1 to consult revocation state on every validation cannot be discharged against a certificate that does not say where that state lives. A relying party MUST NOT treat an unreachable revocation source as an absence of revocation. This restates Section 15.1 and is stated again here because it is the requirement implementations most often relax under operational pressure. 15. Failure Model 15.1. Fail Closed Any verification step that cannot be completed MUST result in DENY. This includes: * CA unreachable * Registry unreachable * CRL unreachable * Certificate expired or revoked * Policy store unreachable, or no policy in force * Scope escalation attempt * Policy invalid or unsigned Trujillo Expires 8 March 2027 [Page 39] Internet-Draft A2A Trust September 2026 * Dual signature missing or invalid Implementations MUST NOT provide a degraded mode that allows partial spawning or execution when verification infrastructure is unavailable. 16. Conformance Requirements 16.1. Field Placement Implementations MUST place every field in the location specified by this document: Section 3, Section 8.2, Section 10.5, Section 11.4, Section 13.2, and Section 10.4. Variable placement is not permitted. 16.2. CSR Validation Non-conforming CSRs MUST be rejected by the CA. A non-conforming template MUST NOT be signed. 16.3. Test Vectors Implementations MUST provide test vectors -- concrete examples of valid and invalid template chains -- for conformance validation. 16.4. Conformance Claims No conformance certification authority exists for this document. An implementation claiming conformance MUST state the revision it claims, as Section 18 describes, and SHOULD publish the results of running the test vectors of Section 16.3 against that revision. A claim without a stated revision is not a conformance claim. 16.5. Reference Implementation A reference implementation SHOULD be made available including: * Template Registry CA * Spawn chain validation * SDK with certificate chain validation, registry lookup, and CRL check handling * Template linter for pre-submission CSR validation Known implementations are listed in Section 18. Trujillo Expires 8 March 2027 [Page 40] Internet-Draft A2A Trust September 2026 17. IANA Considerations 17.1. Object Identifier The Agent Template extension of Section 8.2 and the Agent Spawn extension of Section 10.5 each use an object identifier under the joint-iso-itu-t UUID arc (2.25), which is self-assigning from a UUID and requires no registration. This document requests no allocation from any IANA-managed OID arc. Should this document be adopted, the author is willing to replace them with OIDs under an arc the responsible working group prefers. 17.2. Media Type Registration IANA is requested to register the following media type in the "Media Types" registry, per [RFC6838]. Type name: application Subtype name: a2a-policy+json Required parameters: N/A Optional parameters: N/A Encoding considerations: binary; JSON is UTF-8 encoded and serialized per [RFC8785] Security considerations: See Section 19 of this document. Interoperability considerations: N/A Published specification: This document Applications that use this media type: Multi-agent systems exchanging dynamic policy documents. Fragment identifier considerations: N/A Additional information: N/A Person and email address to contact for further information: Tony Trujillo, founder@phalanxaisec.com Intended usage: COMMON Restrictions on usage: None Trujillo Expires 8 March 2027 [Page 41] Internet-Draft A2A Trust September 2026 Author: Tony Trujillo Change controller: IETF 17.3. Agent Scope Registry IANA is requested to create a registry titled "A2A Agent Scopes", with a registration policy of Specification Required [RFC8126]. Each entry carries a scope name, a description, and a reference. The registry is initially empty; scope names not registered here are private to a deployment and MUST NOT be assumed to carry the same meaning across organizational boundaries. 18. Implementation Status This section records the status of known implementations of the protocol defined by this specification at the time of posting, as described in [RFC7942]. It is meant to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit." _This section is to be removed before publishing as an RFC._ Three independent implementations exist at the time of writing. Each states the revision it was written and verified against, and continues to state that revision until someone re-reads the newer text and re-runs the vectors. An implementation pinned to an earlier revision remains a correct implementation of that revision; a version string is a conformance claim rather than a label, and advancing one without re-verifying asserts conformance nobody has tested. Each is tagged in its repository at the commit implementing the revision named here. Trujillo Expires 8 March 2027 [Page 42] Internet-Draft A2A Trust September 2026 +======================+==========+================================+ | Implementation | Revision | Notes | +======================+==========+================================+ | a2a-trust-playground | -03 | Browser implementation, no | | | | installation or backend. | | | | Mints a Registry, attests and | | | | issues templates, and | | | | validates a chain against | | | | every check in this document, | | | | reporting the clause governing | | | | each refusal. Tagged impl/ | | | | draft-03; the implementation | | | | of -02 remains retrievable at | | | | tag impl/draft-02. Source: | | | | https://github.com/tonyt68/ | | | | a2a-trust-playground | +----------------------+----------+--------------------------------+ | ietf-a2a-trust-poc | -00 | Registry CA, spawn validation | | | | and policy governance | | | | services. Tagged impl/draft- | | | | 00. Source: | | | | https://github.com/tonyt68/ | | | | ietf-a2a-trust-poc | +----------------------+----------+--------------------------------+ | hack-my-own-code | -00 | Adversarial implementation | | | | that attacks its own | | | | conformance. Canonicalizes | | | | with a language-specific JSON | | | | serialization rather than the | | | | scheme required by | | | | Section 11.5, so it does not | | | | conform to that section. | | | | Tagged impl/draft-00. Source: | | | | https://github.com/tonyt68/ | | | | hack-my-own-code | +----------------------+----------+--------------------------------+ Table 12: Known Implementations All three are maintained by the author of this document. They are independent in the sense that they share no code and were written against the specification text rather than against each other; they are not independent in the sense [RFC7942] most values, and a reviewer should weigh them accordingly. An implementation by an unrelated party would be more informative than all three, and is actively sought. Trujillo Expires 8 March 2027 [Page 43] Internet-Draft A2A Trust September 2026 19. Security Considerations 19.1. Scope Escalation Implementations MUST enforce at every hop that child agent scopes are a subset of parent scopes: child scopes are contained within parent scopes, and no scope may be introduced that the parent does not already hold. Failure to enforce this allows privilege escalation across the agent chain. 19.2. Replay Attacks A spawn request MUST carry a timestamp and a nonce, both generated by the spawning agent. The timestamp MUST be an [RFC3339] instant in UTC. The nonce MUST be at least 128 bits of output from a cryptographically secure random number generator, encoded as base64 [RFC4648]. The nonce and timestamp of an accepted request are recorded in the child's Agent Spawn extension (Section 10.5); those of every request, accepted or refused, are recorded in the audit log entry of Section 10.4. The Registry is the relying party for a spawn request. It MUST record the nonce when the request carrying it is received, before any step of Section 10.2 is evaluated, and MUST refuse a later request carrying the same nonce whatever became of the first. A nonce is spent by being presented, not by being accepted: a request refused at any step has consumed its nonce, and a retry MUST carry a fresh one. Recording only accepted nonces would let a refused request be replayed until something changed and it was accepted, and a fresh nonce costs nothing to generate. A relying party MUST refuse a spawn request whose timestamp is more than 60 seconds from the relying party's own clock in either direction, and MUST refuse a request whose nonce it has already seen within that window. A relying party MUST retain seen nonces for at least twice the freshness window. Retaining them for exactly the window leaves a request replayable at the boundary, when the record has been discarded but the timestamp is still inside the window at the receiver. The window is specified rather than left to the deployment because a value chosen independently at each end is not a shared window, and the wider of the two is the one an attacker gets. Accepting a request from the future by the same margin accommodates clock skew; an implementation that accepts only past timestamps will reject legitimate requests from a peer whose clock is marginally ahead. The window assumes clocks synchronized to within a small fraction of it. An operator whose clocks cannot meet that assumption MUST treat it as Trujillo Expires 8 March 2027 [Page 44] Internet-Draft A2A Trust September 2026 a failure condition under Section 15.1 rather than widen the window; a wider window is a longer replay opportunity for every party, not a fix for one party's clock. Sixty seconds tolerates the skew of any correctly administered clock -- NTP holds hosts within milliseconds -- and bounds the nonce retention obligation of a Registry to two minutes. It is deliberately tighter than the five minutes Kerberos [RFC4120] adopted: that tolerance was sized for human-operated hosts with unsynchronized clocks, and a spawn request is a sub-second exchange between machines. A window sized for the former is a longer replay opportunity than the latter needs, and a peer whose clock is more than a minute wrong is not a peer to be accommodated. 19.3. Compromised Templates A compromised template certificate MUST be revoked immediately. A single CRL update invalidates all downstream agent certificates derived from that template. 19.4. Single Point of Compromise The dual signature requirement (Section 11.3) ensures no single compromised party can push unauthorized policy changes. CA compromise requires full ecosystem re-issuance. Compromise of an Owner or Policy Authority key is handled by revoking its certificate under Section 14. Policies and templates signed under the compromised key MUST be re-signed under replacement keys, because a relying party cannot distinguish a signature made before the compromise from one made after it; a revoked signing certificate invalidates every signature it ever produced, not only the fraudulent ones. 19.5. Cross-Organizational Trust Cross-organizational grants MUST be explicitly issued. Implicit trust between organizations is prohibited. 19.6. PKI Does Not Enforce Authorization Because agent identity is carried in X.509 certificates and the chain is verified on every validation, it is natural to assume the certificate chain also constrains what an agent may do. It does not, and an implementation built on that assumption is unprotected while appearing rigorous. Trujillo Expires 8 March 2027 [Page 45] Internet-Draft A2A Trust September 2026 X.509 carries no representation of the scopes defined by this document. AllowedScopes, CanSpawn and MaxChildren are conveyed in the template, and no certificate path validation algorithm inspects them. A conformant X.509 validator presented with an agent certificate whose associated template claims scopes far beyond those its parent holds will report success, because the certificate is genuinely valid and correctly issued. The over-scoping is not a defect the validator is looking for. The nameConstraints extension does not close this gap. It constrains the namespace within which a CA may issue, not the authority a subject may claim once issued. Likewise certificatePolicies expresses which policies a chain supports, not whether a child exceeded its parent, and policy processing is disabled by default in common implementations. Consequently Section 8.3 and Section 10.3 are load-bearing implementation logic. They are not restatements of a property the certificate chain already guarantees, and an implementation that omits them because "the chain verifies" has no containment at all. Certificate validity establishes identity. Authorization is evaluated separately, every time. 19.7. Audit Integrity Audit logs MUST be tamper-evident. Logs MUST NOT be deletable by agents or orchestrators. Audit log infrastructure SHOULD be outside the control of the agent ecosystem itself. Each entry's hash MUST be computed as SHA-256, or a stronger digest, over the canonical form (Section 11.5) of every member of Table 6 other than entry_hash -- that is, including previous_hash and excluding the entry's own hash. As with policy documents, an unspecified preimage is not a detail: two implementations hashing different field sets each read the other's chain as broken, and a chain that cannot be verified across implementations provides no evidence to anyone but its author. 19.8. Privacy Considerations The Owner member of a template is carried inside a certificate that is presented to every relying party the agent ever contacts. An Owner value that identifies a person -- an email address, as the examples in this document use for readability -- is therefore personal data disclosed to every counterparty. Deployments SHOULD populate Owner with an identifier that is opaque outside the owning organization, and resolve it to a person only within that organization. Trujillo Expires 8 March 2027 [Page 46] Internet-Draft A2A Trust September 2026 A version 7 agent identifier discloses the agent's creation time to every party that sees the identifier, as Section 7.2 describes. Audit records required by Section 10.4 carry agent identifiers and scopes, and Section 13.5 places one such record in each organization party to a cross-organizational spawn; the OrgID of each is disclosed to the other by the grant itself. 19.9. Algorithm Agility The signature algorithms of Table 2 and the key strength floor of Section 7.1 are classical. This document does not specify a post- quantum signature algorithm, because no X.509 profile for one had reached the stability this document requires at the time of writing. The per-key-type mapping is the extension point: a future revision adds a row for a post-quantum key type without changing the envelope or any other structure, and a relying party that does not recognize a key type refuses the signature, which is the fail-closed outcome Section 15.1 requires. 19.10. Parsing Untrusted Input Every document this specification defines reaches a relying party from the party whose authority it describes, and is attacker- controlled input until a signature over it has been verified. Section 8.2 states this for the two certificate extensions; it applies equally to a signature envelope, a chain document, and a grant. Three rules of this document exist for that reason and are restated here so that they are read as one defence. The shape rules of Section 3 -- flat objects, no duplicate members, exact wire names, a fixed member set -- mean a conforming parser accepts only the shapes this document defines and has nothing else to be confused by. The size limits of Section 8.2 bound what a parser is asked to read. And the ordering that section requires -- for a certificate, verify the issuer's signature before decoding an extension; for an envelope, verify the signatures over the body octets before acting on any member of body -- means input nobody signed is discarded before it is interpreted. A relying party that parses first and verifies afterwards has exposed its parser to every party able to present a certificate, which is every party. 20. References 20.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . Trujillo Expires 8 March 2027 [Page 47] Internet-Draft A2A Trust September 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, January 2017, . [RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure", RFC 8410, August 2018, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, . [SP800-57] Barker, E., "Recommendation for Key Management: Part 1 - General", NIST SP 800-57 Part 1 Rev. 5, May 2020, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017, . [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, May 2024, . Trujillo Expires 8 March 2027 [Page 48] Internet-Draft A2A Trust September 2026 20.2. Informative References [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, July 2016, . [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012, . [RFC8693] Jones, M., Campbell, A., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, January 2020, . [NIST800-207] Rose, S., Borchert, O., Mitchell, S., and S. Connelly, "Zero Trust Architecture", NIST SP 800-207, August 2020. [SPIFFE] SPIFFE Project, "Secure Production Identity Framework for Everyone", . [OpenFGA] OpenFGA Project, "OpenFGA Specification", . [VAULTPKI] HashiCorp, "Vault PKI Secrets Engine", . Appendix A. Changes since draft-tonyai-a2a-trust-02 As with the previous revision, every change here was surfaced by implementing the -02 text rather than by re-reading it. Three implementations of one specification produced three different answers to the same questions, which is what the changes below exist to prevent. * Specified how documents are encoded on the wire (Section 3). Field tables throughout -02 gave display names only, so implementations invented their own member names and produced signatures no other implementation could reproduce. * Specified the signature envelope (Section 3.1). -02 required two signatures but never said where they live, how they are encoded, or that they are excluded from the body they sign. It also Trujillo Expires 8 March 2027 [Page 49] Internet-Draft A2A Trust September 2026 declared that a policy document carrying any undefined field must be refused, which forbade the signature fields the same document requires. * Specified the encoding of the static template fields (Section 8.2). -02 listed which fields a template carries but never said where in the certificate they live, so two implementations conforming to the text could not validate each other's certificates. * Specified the binding between an agent's identity and its certificate (Section 7.2), and required every restatement of an agent identifier to agree with the certificate subject. -02 carried the identifier in three places and required no agreement among them, so a chain naming one agent while presenting a certificate issued to another validated cleanly. * Specified the form of an agent identifier (Section 7.2). -02 did not mention UUIDs at all, while one implementation refused anything that was not a lowercase version 4; an implementation reading only the text could have used any string and been conformant. * Specified how a template is authored and attested before issuance (Section 9). -02 described what a template contains and how an issued certificate is validated, but not how a template comes to exist, so the conformance gate and dual attestation that existing implementations perform were unspecified. * Specified the nonce and freshness window for replay prevention (Section 19.2). -02 required "a timestamp and nonce" and a "defined freshness window" without defining either, which a conforming implementation could satisfy with an eight-bit nonce and a window of a day. * Required certificates to say where their revocation state lives (Section 14.4). -02 required revocation to be consulted on every validation without requiring any means of finding it. * Specified the encoding of spawn provenance (Section 10.5). -02 issued a child certificate "with parent identity embedded" and a nonce, and gave neither a location. The link from child to parent lived in an unsigned chain document, so the provenance the Introduction calls cryptographically traceable was asserted rather than attested. Trujillo Expires 8 March 2027 [Page 50] Internet-Draft A2A Trust September 2026 * Corrected the certificate chain figure (Section 7.4), which showed an agent certificate issuing a child certificate -- forbidden by Section 7.1 -- and non-UUID subjects, forbidden by Section 7.2. * Typed the cross-organizational grant fields (Section 13.2) and removed the row that listed a signature as a field of the grant; signatures are envelope members. Bounded a policy's NotAfter by the certificate's notAfter rather than by a duration it could not be compared against. * Stated who holds the count that MaxChildren is compared against (Section 10.2). -02 required the comparison and named no party to perform it, so a distributed deployment had no defined owner of the state and two concurrent spawns could both succeed. The Registry enforces the cap atomically; a relying party's document- local count is a consistency check. * Made duplicate-member detection a requirement on the parser (Section 3), not only a property of the document. A stock JSON parser silently keeps one of two duplicates and reports success, which satisfied the -02 wording while defeating its purpose. * Defined scope syntax and set semantics (Section 10.3). -02 required byte comparison of wire names and said nothing about scope values, so whether Read:Data equalled read:data, whether array order mattered, and whether an empty request satisfied the subset test were all implementation-defined. * Named the party that performs the spawn sequence and issues the child certificate (Section 10.2). -02 stated the issuance in the passive voice, and the only party a reader would guess is the one Section 7.1 forbids. * Defined the value space of PermittedOperations and tied spawn to the right to spawn (Section 8.1, Section 10.1). -02 required the field, typed it, showed values in examples, and assigned no meaning to any of them. * Stated what makes a root legitimate (Section 10.5), gave an absent NotAfter a meaning (Section 11.4), gave a grant an issuance instant so its TTL has an origin (Section 13.2), and bound a certificate's validity period to its ttl_seconds (Section 9.3) so that the TTL is enforced by path validation. Clarified that the bounds check of Section 8.3 is independent of signature validity but not prior to it. Trujillo Expires 8 March 2027 [Page 51] Internet-Draft A2A Trust September 2026 * Added threat coverage for the encodings this revision specifies (Section 11.8), stated the rationale for the freshness window (Section 19.2), clarified that the window governs the request and not later validation (Section 10.5), and stated that what a scope grants access to is outside this document (Section 10.3). * Specified the signature algorithm per signer key type (Section 3.1): RSASSA-PSS or ECDSA with a fixed-width value, and no algorithm identifier in the envelope. -02 said "raw signature value" and "SHA-256 or stronger" with no way to signal which, so two implementations could not verify each other's signatures. * Specified how a relying party trusts the Owner and Policy Authority keys (Section 9.2, Section 13.3) and bound the Owner field to the Owner certificate's subject. -02 required the signatures and said nothing about the keys. * Defined Relying Party, Owner, and Root Orchestrator, stated that a template defines exactly one agent, and stated that the Registry and its CA are one logical entity (Section 4). Stated that a new template version keeps its Subject and revokes the prior certificate (Section 12.1), that DISABLED is a Registry state reported in Check 2 rather than a CRL entry (Section 12.4), and which organizations may own a child template under Check 2 (Section 10.1). * Replaced the conformance certification requirement, which named no certifying body, with a conformance claim (Section 16.4). Added Privacy Considerations and Algorithm Agility, and the handling of a compromised Owner or Policy Authority key. Adopted the BCP 14 boilerplate of [RFC8174] and moved the document to the IETF stream and the Security Area. * Hardened the profile with no allowance for prior implementations, which are retained under tags. Both certificate extensions are now critical (Section 8.2), so a validator that does not implement this document refuses the certificate instead of treating it as an ordinary client certificate. The key strength floor rose to 128 bits, RSA-2048 is refused, EC and Ed25519 are recommended, keyUsage is restricted to digitalSignature, and serial numbers require 64 bits of entropy (Section 7.1). Ed25519 joined the signature algorithms. The two-roles-one-key rule now compares keys rather than signature octets, which a randomized scheme made necessary (Section 3.1). Certificate lifetime is capped at seven days (Section 9.3). Timestamps require the Z designator and the JSON objects are declared flat (Section 3). The Grantor's Registry was named as the enforcer of MaxSpawns (Section 13.2). Trujillo Expires 8 March 2027 [Page 52] Internet-Draft A2A Trust September 2026 * Replaced the IANA Considerations section, which previously declared no actions. Specifying the dynamic policy as a standalone JSON document made a media type necessary, and defining scope syntax made a scope registry possible. * Promoted the implementation table to a top-level Implementation Status section per [RFC7942]. * Made the dynamic policy govern spawning (Section 10.1, Section 10.2). The policy document carried a SpawnTargets member that no check consulted, so a policy granting no spawn targets left an agent able to spawn everything its certificate's CanSpawn allowed. The spawn sequence now has a policy step, and each of its steps is assigned to one of the two checks so that an implementer reading the rule alone builds all of them. * Stated who generates the spawn nonce and when it is spent (Section 19.2, Section 10.5). The text had the agent supplying the nonce in one place and the Registry issuing it in another. The agent generates it; the Registry records it on receipt, whether or not the request is then refused; and the document-local uniqueness check is a consistency check rather than the enforcement of uniqueness, which a relying party holding one chain cannot perform. * Bounded MaxChildren by the size of CanSpawn (Section 8.1) and required the Registry to refuse a second live certificate for one child template (Section 10.2). A template defines one agent, so a cap above the number of named children was a cap on nothing, and the example in Section 7.4 showed exactly that. * Removed Issuer from the static field table (Section 8.1). It was REQUIRED there and declared to have no member in the extension two sections later, so the conformance gate demanded a value that could never be supplied. * Tied an issued certificate to the grant that authorized it: a grant carries a GrantID (Section 13.2), a cross-organizational spawn records it in the Agent Spawn extension (Section 10.5), and revoking the grant revokes those certificates (Section 13.4). The requirement that agents spawned under a revoked grant be treated as untrusted recorded nothing that identified them. * Gave the audit log entry a member table (Section 10.4), the extension size limit a value (Section 8.2), the policy document table a type column (Section 11.4), the content hash a stated scope (Section 11.6), string equality one rule (Section 3), and the serial number its DER encoding (Section 7.1). Redrew the CSR Trujillo Expires 8 March 2027 [Page 53] Internet-Draft A2A Trust September 2026 flow (Section 7.3) to show the dual attestation that Section 9.2 requires, added Section 19.10, listed every field-bearing section in Section 16.1, and moved OAuth 2.0 and Token Exchange to the informative references, since neither is needed to implement anything here. Appendix B. Changes since draft-tonyai-a2a-trust-01 Section numbers in this appendix are those of draft-tonyai-a2a-trust- 02, the revision these changes produced. Several sections were renumbered in -03; see Appendix A. All changes in this revision were surfaced by building a second, independent implementation of the -01 text and attacking it. Changes are described below by their effect on a conformant implementation rather than by intent: where an implementation conforming to -01 must change to remain conformant, this is stated plainly, because an implementer reading this appendix is deciding whether re-verification is required. Four changes below are breaking. Two implementations exist at the time of writing, both under the author's control; the cost of these changes is at its minimum now and rises permanently once a third- party implementation ships. *Security fix -- breaking.* * Section 9.6 (Signature and Hash Coverage) is new, and requires that Version and Subject be inside the signed preimage. In -01 the policy version was listed in Section 9.4 as a value stored alongside the signature, and the text never required the signature to cover it. Both existing implementations read it that way and neither signed the version, which defeats the replay prevention that Section 9.4 assigns to that field: an attacker holding no key can take a superseded but validly signed policy, increment the version, and have it accepted -- both signatures verify, the content hash matches, and the version reads as current. Implementations MUST re-sign existing policies under the new coverage. Signatures produced under -01 do not verify under -02. *Interoperability -- breaking.* * Section 9.5 (Canonicalization) is new, and normatively specifies JCS (RFC 8785) as the serialization for all signatures and hashes. -01 contained no canonicalization text of any kind, which made Section 9.3 impossible to implement interoperably: a signature is over bytes, and nothing in -01 said how those bytes are produced. The only way to implement -01's dual signature was to read an Trujillo Expires 8 March 2027 [Page 54] Internet-Draft A2A Trust September 2026 existing implementation's source. JCS differs from what both current implementations do, so both must change and all existing signatures and test vectors are invalidated. An existing implementation is not conformant to -02 by default. * Section 9.4 (Dynamic Policy Document Structure) is new. -01 required the dynamic policy to be signed, hashed, stored and integrity-checked without ever defining what it contains, leaving each implementer to invent a field set. Different invented sets produce different signatures and different hashes for the same policy, and each implementation reads the other's documents as tampered with. Implementations whose field set differs from the table in Section 9.4 must change. *New normative requirements -- additive.* * Section 6.3 (Certificate Profile) is new. -01 mandated X.509 and specified no profile: no key strength, no digest floor, and no basicConstraints requirement. Three certificates that verify under a conformant X.509 validator were accepted as agent identities by an implementation conforming to -01 -- one asserting cA = TRUE, one signed with SHA-1, and one carrying no basicConstraints at all. The first is also a containment failure: an agent whose certificate permits it to issue certificates can create children without presenting a request to the CA, which removes both checks in Section 8.1 from the spawn path without invalidating any signature. Implementations already issuing cA = FALSE, SHA-256, RSA-2048 leaves satisfy this section unchanged, but MUST add the corresponding checks on validation. * Section 7.2 now states who enforces the dynamic policy bounds, when, and with what result. -01 stated the rule and named no enforcement point, so an implementation that never checked it and one that checked it before signature verification both read as conformant while returning different results for the same document. The bounds MUST now be evaluated independently of signature validity and refused before the policy is applied. *Rename -- breaking.* * The Section 7.1 static field KeyUsage is renamed PermittedOperations. The field carries the operations an agent may perform -- spawn, delegate, read -- and is unrelated to the X.509 keyUsage extension, whose values are digitalSignature, keyCertSign and the rest of the RFC 5280 set. The collision was latent while this document never referred to the X.509 extension; Section 6.3 now does, normatively, so a single document used one name for two unrelated things. RFC 5280 owns the name keyUsage, Trujillo Expires 8 March 2027 [Page 55] Internet-Draft A2A Trust September 2026 so the template field is the one that moves. The new name is the description this document already gave the field. Implementations MUST rename the corresponding metadata field; the value space is unchanged. *Removal -- breaking for any implementation reading the field.* * The ScopeInherit field is removed from the Section 7.1 static field table. It was REQUIRED in -00 and -01 with no defined value space, and the value both existing implementations populate it with, "strict-subset", contradicts Section 8.3 as clarified in -01, which explicitly permits equality. Neither implementation reads the value, so the field conveyed no capability; Section 8.3 already determines inheritance completely. An implementation that enforced the field literally would deny a child legitimately holding its parent's full scope set, which is the misreading -01 was published to prevent. *Non-normative.* * Section 16.7 (PKI Does Not Enforce Authorization) is new. It states that certificate validity establishes identity and not authorization, that neither nameConstraints nor certificatePolicies closes that gap, and that Sections 7.2 and 8.3 are therefore load-bearing implementation logic rather than restatements of a guarantee the chain already provides. No behaviour changes; the omission was judged the most likely to cause an implementer to build something that verifies correctly and contains nothing. Appendix C. Changes since draft-tonyai-a2a-trust-00 Section numbers in this appendix are those of draft-tonyai-a2a-trust- 01, the revision these changes produced. Clarified two areas identified as ambiguous during development of a reference implementation: * Section 8.3/16.1 scope-subset language now explicitly permits equality between a child's requested scope and its parent's granted scope; only escalation (a superset) is prohibited. The prior wording could be misread as requiring a strict/proper subset, which would wrongly deny a child that legitimately needs the same scope as its parent. Trujillo Expires 8 March 2027 [Page 56] Internet-Draft A2A Trust September 2026 * Section 12.1 revocation-check language now explicitly accepts an X.509 CRL, an OCSP responder, or an equivalent revocation registry, rather than implying a CRL specifically. The normative requirement is that revocation state is consulted on every validation, not the specific mechanism used to represent it. Neither change alters the normative requirements themselves; both make explicit what the -00 text intended. Both were surfaced by building and red-teaming a conformance reference implementation against the -00 text. Author's Address Tony Trujillo (tonyai) Individual Submission Email: founder@phalanxaisec.com Trujillo Expires 8 March 2027 [Page 57]