Merkle Tree Agent Certificates (MTAC): A Merkle Tree Certificates Profile for AI Agent Identity

1.1. Problem

AI agents increasingly act across organizational boundaries, on behalf of people and of other agents. In this document "agent" means an AI agent as defined in Section 2. After an agent has acted, a relying party, auditor or investigator often needs to determine three things: which agent instance acted, which organization a CA recorded as accountable for it, and what model and configuration were declared for it at the time. They may need to determine this without network access to the issuer, and over a period longer than classical signatures are expected to resist a cryptographically relevant quantum computer.¶

An identity credential does not make an agent safe. An agent whose identity and permissions are all valid can still be induced to misuse access it legitimately holds. Preventing that needs controls on what an agent can reach and do, enforced outside the model, which this document does not specify. It addresses the narrower question those controls leave open: which identifier and declared configuration a CA bound to a key, and when.¶

1.2. Approach

Merkle Tree Certificates [I-D.ietf-plants-merkle-tree-certs] (MTC) define X.509 certificates whose authenticity comes from inclusion in a CA-operated issuance log, cosigned by the CA and optionally by other cosigners, rather than from a per-certificate signature. MTC states that "X.509 extensions apply to Merkle Tree Certificates without any modifications" and that other documents may define cosigner roles. This document uses both extension points and defines no new log, tree, proof or signature format.¶

This document specifies:¶

• a profile of the certificate contents for an AI agent subject, in which the subject is named by a workload identifier [I-D.ietf-wimse-identifier] (Section 4);¶

• three certificate extensions describing the agent (Section 5);¶

• an audit cosigner role (Section 6);¶

• an audit verification procedure for a relying party that verifies a certificate after the fact and possibly offline (Section 8.3);¶

• how an MTAC certificate relates to workload identity credentials (Section 10) and to transparency-service records of agent actions (Section 11).¶

Because an MTAC certificate is an X.509 certificate with exactly one URI subject alternative name carrying a workload identifier, it is also a Workload Identity Certificate as described in [I-D.ietf-wimse-workload-creds].¶

1.3. Relationship to the previous version

The previous version of this document [I-D.burls-mtac] specified a standalone credential format: a CBOR leaf, a bespoke signed tree head, a bespoke witness note and a bespoke holder commitment. Its stated distinguishing property, issuance by batch, is also the design of MTC, which applies it to any X.509 subject. This version therefore replaces the standalone format with a profile of MTC. Appendix D maps each element of the previous format to its counterpart here.¶

1.4. What this document does not specify

A relying party MUST NOT infer any of the following from a successful verification under this document.¶

• Authorization. Declared scopes (Section 5.2) are recorded at issuance as the requesting party stated them. They are not permissions. This document defines no mechanism by which they constrain an agent, and a relying party MUST NOT treat a declared scope as evidence that the agent operated within it.¶

• Behavior. Verification establishes that a certificate was issued and logged, and what it declared. It does not establish what the agent subsequently did.¶

• Action records. No format for records of agent actions is defined; Section 11 describes how such records can refer to an MTAC certificate.¶

• Runtime attestation. A configuration claim marked as declared (Section 5.3) is a statement made at issuance. It is not evidence that the declared model or configuration was the one that executed.¶

• Authority of the sponsor. The sponsor, capacity and mandate fields (Section 5.1) record what the CA was told and, under its policy, checked. They are not evidence that the sponsor has authority over the agent, that the requester could bind the sponsor, or that the sponsor has any legal duty for the agent. Those are matters for law and for the parties' arrangements.¶

• Presenter identity. Holding the certificate bytes says nothing about the presenter. A proof of possession (Section 7) shows control of the certified key, not that the presenter is the agent named in the certificate.¶

4.1. Version

The version MUST be v3, because the profile uses extensions.¶

4.2. Subject and agent identifier

The agent identifier MUST be a workload identifier as defined in Section 4.1 of [I-D.ietf-wimse-identifier]: an absolute URI whose authority component is the trust domain, with no query, fragment, user information or port component.¶

The certificate MUST contain a subjectAltName extension [RFC5280] with exactly one GeneralName of type uniformResourceIdentifier, and that GeneralName is the agent identifier. The certificate MAY contain subjectAltName entries of other types. With these rules the certificate meets the subject naming requirements for a Workload Identity Certificate in Section 6.1 of [I-D.ietf-wimse-workload-creds].¶

The subject field SHOULD be an empty sequence. When it is empty, the subjectAltName extension MUST be marked critical, as Section 4.2.1.6 of [RFC5280] requires.¶

Relying parties MUST compare agent identifiers as complete URIs, as Section 4.3 of [I-D.ietf-wimse-identifier] requires.¶

An agent identifier names one agent instance. An issuer MUST NOT use the same agent identifier for two agent instances. Several certificates for the same identifier can be valid at once, for example during renewal and key rotation as Section 10.4 of [I-D.ietf-plants-merkle-tree-certs] recommends, or briefly after a configuration change (Section 5.3.1). A relying party therefore MUST determine the key and the declared configuration from the certificate actually presented or referenced, and not from the identifier alone.¶

A CA MUST NOT issue an MTAC certificate for an agent identifier in a trust domain it is not authorized for under its certificate policy. Relying parties MUST bind each trust domain to the CA IDs authorized to issue for it, as Section 3 of [I-D.ietf-wimse-workload-creds] requires of consumers, and MUST reject a certificate whose issuing CA is not authorized for the identifier's trust domain. A relying party MAY enforce the binding by supplying the authorized trust domains as initial-permitted-subtrees (Section 6.1.1 of [RFC5280]) or as trust anchor constraints [RFC5937]. Name constraints placed in an MTC CA certificate are not processed when that certificate is used as a trust anchor.¶

4.3. Subject public key

The subjectPublicKeyInfo carries the agent instance's public key. This document does not restrict its algorithm. Deployments that require post-quantum protection for the agent's own signatures SHOULD use ML-DSA [FIPS204] as specified for X.509 in [RFC9881]. Recommendations for long-lived records are in Section 13.¶

The keyUsage extension, if present, MUST include digitalSignature and MUST NOT include keyCertSign. The basicConstraints extension, if present, MUST NOT assert cA.¶

4.4. Validity

notBefore and notAfter have their [RFC5280] meaning: the period during which the CA vouches for the binding. Issuers SHOULD keep validity short, in line with the guidance in [I-D.ietf-wimse-aims] that agent credentials be short-lived. Because each issuance run costs each cosigner a small constant number of signatures however many certificates it covers (Section 6.3 of [I-D.ietf-plants-merkle-tree-certs]), short validity does not multiply signing cost. It does increase log size and monitoring load (Section 10.1 of that document).¶

An audit relying party evaluates validity against a time of interest, not only against the time of verification. Section 8.3.3 defines how the two are reported.¶

4.5. Profile extensions

An MTAC certificate MUST contain the Agent Sponsor extension and MAY contain the other extensions defined in Section 5. Each of them MUST be marked non-critical. A relying party that does not recognize them is not affected by ignoring them, because none of them grants anything.¶

4.6. Issuance requirements

An MTAC CA MUST make the standalone form of every MTAC certificate available to the subject, even when it also issues a landmark-relative form, and MUST include in every standalone MTAC certificate a subtree signature from at least one audit cosigner (Section 6) in addition to its CA cosigner signature. Without one, the certificate cannot pass audit verification (Section 8.3).¶

The material that dates issuance (Section 6.2) is a timestamped checkpoint and a subtree consistency proof, and MTC permits CAs and mirrors to stop serving old entries (Section 10.3 of [I-D.ietf-plants-merkle-tree-certs]). An MTAC CA SHOULD therefore deliver to the subject, as soon as an audit cosigner has signed a timestamped checkpoint covering the certificate, that checkpoint signature and the subtree consistency proof between the certificate's subtree and that checkpoint. Because a CA usually requests a checkpoint cosignature before collecting subtree cosignatures (Section 6.3 of [I-D.ietf-plants-merkle-tree-certs]), such a checkpoint normally exists at issuance. Any party that retains an MTAC certificate for later audit is responsible for retaining this material with it.¶

5.1. Agent Sponsor

id-pe-mtacAgentSponsor OBJECT IDENTIFIER ::= { id-pe TBD1 }

AgentSponsor ::= SEQUENCE {
    sponsor   GeneralNames,
    capacity  [0] UTF8String (SIZE (1..MAX)) OPTIONAL,
    mandate   [1] IA5String (SIZE (1..MAX)) OPTIONAL,
    ... }

The Agent Sponsor extension names the sponsor: the party that requested the certificate and that the CA records as accountable for the agent instance. It is the one extension every MTAC certificate MUST contain. A relying party that implements this profile recognizes an MTAC certificate by the presence of this extension, and a party that does not implement it treats the certificate as an ordinary Merkle Tree Certificate.¶

sponsor is one or more GeneralNames that all identify the same sponsor, for example one organization by register code and by directory name. It MUST NOT name different parties. A deployment can name the sponsor with whatever identifier its context already uses, for example a directoryName for an organization registered in a legal entity register, a uniformResourceIdentifier, or an rfc822Name. A URI that names an organization by a register code, using a scheme the deployment defines or adopts, is RECOMMENDED where such a register exists, because it is stable and language neutral. This document defines no such scheme.¶

capacity, when present, is text naming the office or role in which the sponsor acts for this agent, for example "authorised signatory". It is declared, not verified, unless the CA's certificate policy states otherwise.¶

mandate, when present, is a URI [RFC3986] that points to an external authorization under which the sponsor acts or acted, for example a signed power of attorney or an entry in a mandate register. MTAC does not store, fetch or evaluate the mandate, and a relying party MUST NOT treat the presence of this field as evidence that any authority exists or that the mandate is valid, current or covers this agent. The URI is recorded in a log that many parties can read: it MUST NOT contain a credential, token, or any value that grants access, and a relying party MUST NOT dereference it automatically.¶

An agent is not a legal person under this document, and nothing in an MTAC certificate gives an agent legal capacity. The sponsor can be a natural person or a legal person; the extension records which one the CA recorded as accountable. Whether and how the law holds that party responsible for the agent is outside this document.¶

The CA MUST validate the sponsor's identity, and SHOULD establish that the requester is entitled to name that sponsor, to the level its certificate policy states before including this extension. This document does not define such a level. A relying party learns from this extension only that the CA, under its own policy, recorded this sponsor as accountable.¶

The names in this extension are not subject to name constraints, which apply only to subject names and subject alternative names. They are not subject alternative names and are not matched as such. Issuers SHOULD name an organization rather than a natural person; see Section 16.¶

5.2. Declared Scopes

id-pe-mtacDeclaredScopes OBJECT IDENTIFIER ::= { id-pe TBD2 }

DeclaredScopes ::= SEQUENCE SIZE (1..MAX) OF
                       UTF8String (SIZE (1..MAX))

The Declared Scopes extension records, as text, the operation classes the sponsor declared for the agent instance at issuance. This document defines no vocabulary for the strings; deployments agree on one among themselves. They are intended for an auditor, who can later compare the operation classes the sponsor declared with what the sponsor and agent actually did, using records outside this document. A declaration can go stale; a changed declaration is a new certificate (Section 5.3.1).¶

Declared scopes are not authorization. A relying party MUST NOT treat a declared scope as a permission or as evidence of behavior. In particular, an implementation MUST NOT map a declared scope to an OAuth scope or authorization_details value without a separate authorization decision.¶

The order of the strings has no defined meaning.¶

5.3. Agent Configuration

id-pe-mtacAgentConfiguration OBJECT IDENTIFIER ::= { id-pe TBD3 }

AgentConfiguration ::= SEQUENCE SIZE (1..MAX) OF
                           ConfigurationComponent

ConfigurationComponent ::= SEQUENCE {
    role       UTF8String (SIZE (1..MAX)),
    name       [0] UTF8String (SIZE (1..MAX)) OPTIONAL,
    version    [1] UTF8String (SIZE (1..MAX)) OPTIONAL,
    digest     [2] ComponentDigest OPTIONAL,
    reference  [3] IA5String (SIZE (1..MAX)) OPTIONAL,
    source     ClaimSource,
    ... }

ComponentDigest ::= SEQUENCE {
    algorithm  AlgorithmIdentifier{DIGEST-ALGORITHM,
                                   {DigestAlgorithmSet}},
    value      OCTET STRING }

ClaimSource ::= ENUMERATED {
    declared        (0),
    issuerVerified  (1),
    attested        (2),
    ... }

The Agent Configuration extension records the components declared for, or verified by the CA for, the agent instance: which model, which runtime, which configuration, and optionally which data sets.¶

role names the kind of component. This document defines the following values. Any other value MUST be an absolute URI under the control of the party that defines it, so that independently defined roles do not collide.¶

name and version are human-readable labels. They are informative and SHOULD NOT be the basis of an automated decision on their own.¶

digest, when present, is a cryptographic digest of the component or of a description of it. This document does not define what is digested; that is identified by reference or by a deployment profile. Two parties can compare digests only if they agree on that input. The AlgorithmIdentifier parameters MUST be absent, and the length of value MUST equal the output length of the algorithm, so that each digest has one encoding. The algorithm MUST be one the relying party's policy accepts. The ASN.1 type admits the SHA-2 algorithms of [RFC5912] and is extensible; this document does not choose one.¶

reference, when present, is a URI [RFC3986], following the rules of Section 7.4 of [RFC5280] for URIs in certificates, at which more information about the component can be found, for example an Entity Attestation Token claims set [RFC9711], a model card, or a bill of materials. The CA does not vouch for the content at that URI unless digest covers it.¶

source grades how the CA came to record the component:¶

• declared: the sponsor stated it and the CA recorded it without checking.¶

• issuerVerified: the CA checked it against something under the CA's control or inspection, as described in its certificate policy, before issuance.¶

• attested: the CA appraised remote attestation evidence [RFC9334] for the component before issuance, under a policy its certificate policy states. [I-D.novak-rats-tacra] describes one such issuance flow.¶

A relying party MUST treat a component marked declared as a statement by the sponsor, not as evidence of what executed. A CA MUST NOT mark a component attested on the basis of a name or version string alone. A component marked attested or issuerVerified reflects the CA's appraisal at issuance only. It is not evidence of what ran at any later time, including a time of interest. A relying party that encounters a source value it does not recognize MUST treat the component as declared.¶

This extension does not define a vocabulary for model properties. Deployments that need one SHOULD reference an existing claims format through reference and digest rather than extending this structure. [I-D.palanisamy-scitt-aac-runtime] defines a detailed vocabulary for model, runtime and decoding settings, and also grades each claim by source.¶

6.1. Statements and obligations

Every MTC cosigner is already required to keep the subtrees it signs consistent with each other (Section 5.3.2 of [I-D.ietf-plants-merkle-tree-certs]). An audit cosigner obtains that assurance by checking consistency proofs, as a witness does in [TLOG-WITNESS]. An audit cosigner's subtree signatures make no additional statement about the subtree.¶

An audit cosigner has one operational obligation, which it states in its published policy: it retains every checkpoint signature it produces with a non-zero timestamp, and makes them available to audit relying parties, for at least a stated audit retention period.¶

An audit cosigner makes no statement about the content of any log entry. In particular it does not certify agent identifiers, sponsors, scopes or configurations. Those are the CA's statements alone.¶

6.2. Timestamped checkpoints

An audit cosigner SHOULD sign timestamped checkpoints (non-zero timestamp, Section 5.3.1 of [I-D.ietf-plants-merkle-tree-certs]) at an interval stated in its published policy.¶

A timestamped checkpoint from an audit cosigner serves two purposes for an auditor:¶

• It is a high-water mark. An auditor that holds a timestamped checkpoint of size N can detect a later view of the log that is inconsistent with it.¶

• It dates issuance. If an MTAC certificate's log entry is included in a tree that an audit cosigner signed with timestamp T, the entry existed no later than T, independently of any time the certificate itself states. That date rests on the audit cosigner's clock and honesty, since the timestamp is the cosigner's own statement of when it signed.¶

6.3. Independence

An audit cosigner provides a property beyond the CA cosigner only to the extent that it is operated independently of the CA. An audit cosigner SHOULD be operated by a party administratively independent of the CA. A deployment in which the same party operates the CA and the audit cosigner obtains consistency checking without independence, and an audit relying party SHOULD be told which is the case.¶

Each audit cosigner MUST use a cosigner ID distinct from every other cosigner role its operator performs, as Section 5.3 of [I-D.ietf-plants-merkle-tree-certs] requires.¶

6.4. Algorithms

An audit cosigner MUST sign with a post-quantum signature algorithm, because its signatures are what an auditor relies on long after issuance. Where the cosigning protocol in use supports one, an audit cosigner SHOULD use a signature algorithm from a different family than the CA cosigner, for example SLH-DSA where the CA cosigner uses ML-DSA, so that a break of one signature family does not on its own permit forgery of a certificate an auditor accepts. Deployments should note that the cosignature protocol of [TLOG-WITNESS] does not currently define SLH-DSA, and that SLH-DSA signatures are considerably larger than ML-DSA signatures, which works against the size goals of MTC. Section 5.3.3 of [I-D.ietf-plants-merkle-tree-certs] requires a new cosigner ID for any change of key or algorithm, which fixes the algorithm for every signature under a given cosigner ID.¶

6.5. Public corroboration

An audit cosigner MAY additionally publish its timestamped checkpoints, or digests of them, to an independent public medium. A value published this way corroborates the checkpoint only. It says nothing about the content of any entry, and the availability and durability of the medium are outside the scope of this document.¶

8.1. Online verification

An online relying party performs X.509 path validation as Section 6.1 of [RFC5280] specifies, with the signature verification step replaced by the procedure of Section 7.2 of [I-D.ietf-plants-merkle-tree-certs], under its configuration (Section 7.1 of that document) and cosigner policy (Section 7.3). It then applies the following profile checks:¶

1. The certificate contains exactly one URI subjectAltName, and that URI conforms to Section 4.1 of [I-D.ietf-wimse-identifier].¶

2. The issuing CA is authorized for the trust domain of that identifier (Section 4.2).¶

3. The Agent Sponsor extension is present, and any extension defined in Section 5 decodes as specified (Section 8.2). A relying party MUST reject a certificate in which such an extension is present but does not decode. Unknown values of an extensible field are not decoding failures.¶

4. Where the relying party requires it, proof of possession succeeds (Section 7).¶

8.2. Decoding and what may be relied on

The signature verification of Section 7.2 of [I-D.ietf-plants-merkle-tree-certs] authenticates the TBSCertificate fields exactly as they are copied into the log entry. What a relying party then reads from the certificate must be those same authenticated bytes, and nothing else. Accordingly:¶

• A relying party MUST parse the TBSCertificate, and the value of each extension defined in Section 5, with a conforming DER parser, and MUST reject a value that is not valid DER, including values with non-minimal lengths, trailing octets, or any other encoding a DER encoder would not produce for the same abstract value. Where a value contains no content the relying party does not recognize, re-encoding the decoded value with DER MUST reproduce the received octets exactly. A relying party that does not use a conforming DER parser MUST apply the additional checks of Section 12.6 of [I-D.ietf-plants-merkle-tree-certs].¶

• Every value a relying party reports, records or acts on, including the agent identifier and the contents of every extension in Section 5, MUST be taken from the decoded fields of the TBSCertificate whose signature verification succeeded. It MUST NOT be taken from any other bytes, such as an unverified copy of the certificate, a field supplied alongside it, or a search of the raw encoding.¶

• A relying party MUST NOT compute or verify the entry hash over a re-encoding of only the fields it recognizes. Fields it does not recognize, including unknown additions within an extensible structure, are part of what was authenticated. A relying party MAY disregard their meaning, but when it reports the contents of an extension it MUST indicate that unrecognized content was present rather than presenting the extension as if that content were absent.¶

8.3. Audit verification

This section defines how an audit relying party verifies an MTAC certificate after the fact.¶

13.1. CNSA 2.0

MTAC certificates cannot conform to the Commercial National Security Algorithm Suite 2.0 profile for certificates [I-D.jenkins-cnsa2-pkix-profile]. That profile requires the signature on every certificate to be made with ML-DSA-87, whereas the signature of an MTC certificate is an MTCProof identified by id-alg-mtcProof. It also requires SHA-384 or SHA-512 for other hashing, and a critical keyUsage extension, an extended key usage extension and an authority key identifier in end-entity certificates. ML-DSA-87 can be used for subject keys and cosigners, since this profile fixes none of those algorithms, but conformance would need a CNSA profile that admits MTC proofs; choosing a SHA-384 log hash would not be enough. SLH-DSA, the example of a different signature family given in Section 6, is not a CNSA 2.0 algorithm. The hash-based algorithms CNSA 2.0 does list, LMS and XMSS, are stateful, and no cosignature protocol currently defines them.¶

15.1. Identity is not safety

An MTAC certificate identifies an agent instance and records what was declared about it. An agent with a valid certificate can still be induced to misuse its access. Nothing in this document reduces that risk, and a deployment that treats an MTAC certificate as a control on behavior is relying on something this document does not provide.¶

15.2. Bearer presentation

Without proof of possession (Section 7), presentation of an MTAC certificate is bearer presentation. Relying parties that need to know the presenter controls the certified key MUST require proof of possession explicitly.¶

15.3. Authenticated bytes

A verifier that authenticates one encoding of a certificate but reads its claims from another, for example by hashing a re-encoding of the fields it recognizes, or by searching raw octets for a value, can be made to accept content that was never certified while the signatures still verify. Section 8.2 requires strict DER decoding and requires every reported or acted-on value to come from the authenticated fields.¶

15.4. Dereferencing, free text and size

The mandate and reference fields contain URIs. A relying party MUST NOT dereference them automatically, because doing so lets a certificate request cause network access from the relying party, and the resource can change after issuance. Free text fields (name, version, capacity, declared scopes) can contain characters, including bidirectional controls, that make displayed text differ from what was recorded; relying parties SHOULD display such text with controls neutralized and SHOULD NOT use it in access decisions. Because an MTC log entry has a size limit (Section 5.2.1 of [I-D.ietf-plants-merkle-tree-certs]) and the log is append-only, CAs SHOULD bound the size and number of the strings and components they accept.¶

15.5. Sponsor claims

A CA that does not establish that a requester is entitled to name a sponsor can be used to create a certificate that appears to be sponsored by a party that never agreed to it. The certificate policy of the CA is what a relying party relies on here.¶

15.6. Declared claims

Declared scopes and components marked declared are statements by the sponsor that the CA did not check (Section 5.2, Section 5.3). Treating them as evidence of behavior or of what executed is an error.¶

15.7. Configured cosigner keys

A relying party's configuration names the CA cosigner key, which certifies entries, and any audit cosigner keys, which add consistency checking and dating. A verifier that takes any of these keys from the material it is verifying gains no assurance, because an adversary who supplies a substituted key can supply matching signatures. Audit relying parties need archived keys obtained by a trusted means.¶

15.8. Trust domain authorization

A relying party that skips the trust domain check of Section 4.2 gives every CA it accepts authority over every trust domain.¶

15.9. Cosigner independence

An audit cosigner operated by the same party as the CA does not protect against that party. Audit relying parties SHOULD know which cosigners are independent of the CA and SHOULD require at least one that is.¶

15.10. Revocation and offline verification

A verifier without fresh revocation information can accept a certificate that has since been revoked; see Section 8.3.4.¶

15.11. Key use across protocols

If an agent instance uses its certified key in more than one protocol, for example TLS and COSE, the separation between those uses rests on each protocol's own domain separation. Deployments MAY issue separate certificates for separate key uses.¶

15.12. Key custody

The value of an MTAC certificate depends on the protection of the CA cosigner, audit cosigner and agent keys. This document does not specify key protection. Deployments SHOULD protect CA and cosigner private keys in hardware security modules or equivalent.¶

18.1. Normative References

[I-D.ietf-plants-merkle-tree-certs]

Benjamin, D., O'Brien, D., Westerbaan, B., Valenta, L., and F. Valsorda, "Merkle Tree Certificates", Work in Progress, Internet-Draft, draft-ietf-plants-merkle-tree-certs-07, 7 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-plants-merkle-tree-certs-07>.

[I-D.ietf-wimse-identifier]

Rosomakho, Y. and J. A. Salowey, "Workload Identifier", Work in Progress, Internet-Draft, draft-ietf-wimse-identifier-03, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-identifier-03>.

[I-D.ietf-wimse-workload-creds]

Campbell, B., Salowey, J. A., Schwenkschuster, A., Sheffer, Y., and Y. Rosomakho, "WIMSE Workload Credentials", Work in Progress, Internet-Draft, draft-ietf-wimse-workload-creds-02, 2 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds-02>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.

[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, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/rfc/rfc5280>.

[RFC5912]

Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, <https://www.rfc-editor.org/rfc/rfc5912>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9881]

Massimo, J., Kampanakis, P., Turner, S., and B. E. Westerbaan, "Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA)", RFC 9881, DOI 10.17487/RFC9881, October 2025, <https://www.rfc-editor.org/rfc/rfc9881>.

18.2. Informative References

[FIPS204]

National Institute of Standards and Technology, "Module-Lattice-Based Digital Signature Standard", FIPS 204, DOI 10.6028/NIST.FIPS.204, 13 August 2024, <https://csrc.nist.gov/pubs/fips/204/final>.

[I-D.burls-mtac]

Burls, R., "Merkle Tree Agent Certificates (MTAC): Batch-Issued Post-Quantum Identity Credentials for AI Agents", Work in Progress, Internet-Draft, draft-burls-mtac-00, 21 July 2026, <https://datatracker.ietf.org/doc/draft-burls-mtac/00/>.

[I-D.coetzee-oauth-spt-txn-tokens]

Coetzee, R. J., "Transaction-Bound Authorization Tokens for Software and AI Agents (SPT-Txn)", Work in Progress, Internet-Draft, draft-coetzee-oauth-spt-txn-tokens-03, 19 July 2026, <https://datatracker.ietf.org/doc/html/draft-coetzee-oauth-spt-txn-tokens-03>.

[I-D.elkins-plants-enterprise-mtc-deployment]

Elkins, N. and M. ackermann, "Enterprise Deployment Considerations for Standalone Merkle Tree Certificates", Work in Progress, Internet-Draft, draft-elkins-plants-enterprise-mtc-deployment-00, 17 October 2026, <https://datatracker.ietf.org/doc/html/draft-elkins-plants-enterprise-mtc-deployment-00>.

[I-D.emirdag-scitt-ai-agent-execution]

Emirdag, P. and D. Feichtinger, "AI Agent Execution Profile of SCITT", Work in Progress, Internet-Draft, draft-emirdag-scitt-ai-agent-execution-01, 12 October 2026, <https://datatracker.ietf.org/doc/html/draft-emirdag-scitt-ai-agent-execution-01>.

[I-D.fane-opena2a-aip]

Fane, A., "OpenA2A Agent Identity Protocol (AIP)", Work in Progress, Internet-Draft, draft-fane-opena2a-aip-04, 6 October 2026, <https://datatracker.ietf.org/doc/html/draft-fane-opena2a-aip-04>.

[I-D.gilda-audit-agent-audit-record]

Gilda, S., "An Audit Record Format for AI Agent Authorization Decisions", Work in Progress, Internet-Draft, draft-gilda-audit-agent-audit-record-00, 16 October 2026, <https://datatracker.ietf.org/doc/html/draft-gilda-audit-agent-audit-record-00>.

[I-D.gray-plants-mtc-deploy-use-cases]

Gray, J., Klaußner, J., T, L., and G. Mallaya, "Merkle Tree Certificates Deployment Use Cases", Work in Progress, Internet-Draft, draft-gray-plants-mtc-deploy-use-cases-01, 2 September 2026, <https://datatracker.ietf.org/doc/html/draft-gray-plants-mtc-deploy-use-cases-01>.

[I-D.ietf-lamps-pq-composite-sigs]

Ounsworth, M., Gray, J., Pala, M., Klaußner, J., and S. Fluhrer, "Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for use in X.509 Public Key Infrastructure", Work in Progress, Internet-Draft, draft-ietf-lamps-pq-composite-sigs-19, 21 April 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pq-composite-sigs-19>.

[I-D.ietf-oauth-transaction-tokens]

Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-11, 30 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-11>.

[I-D.ietf-scitt-scrapi]

Birkholz, H., Geater, J., and A. Delignat-Lavaud, "Supply Chain Integrity, Transparency, and Trust (SCITT) Reference APIs", Work in Progress, Internet-Draft, draft-ietf-scitt-scrapi-11, 26 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-scitt-scrapi-11>.

[I-D.ietf-stir-certificate-transparency]

Wendt, C., Śliwa, R., Fenichel, A., and V. A. Gaikwad, "STI Certificate Transparency", Work in Progress, Internet-Draft, draft-ietf-stir-certificate-transparency-04, 17 August 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-stir-certificate-transparency-04>.

[I-D.ietf-wimse-aims]

Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Identity Management System", Work in Progress, Internet-Draft, draft-ietf-wimse-aims-00, 15 September 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-aims-00>.

[I-D.ietf-wimse-arch]

Salowey, J. A., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft-ietf-wimse-arch-08, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch-08>.

[I-D.ietf-wimse-wpt]

Campbell, B. and A. Schwenkschuster, "WIMSE Workload Proof Token", Work in Progress, Internet-Draft, draft-ietf-wimse-wpt-02, 27 August 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-wpt-02>.

[I-D.izmaylov-agent-permission-receipts]

Izmaylov, P., "Signed Permissions and Action Receipts for Automated Agents", Work in Progress, Internet-Draft, draft-izmaylov-agent-permission-receipts-00, 7 October 2026, <https://datatracker.ietf.org/doc/html/draft-izmaylov-agent-permission-receipts-00>.

[I-D.jenkins-cnsa2-pkix-profile]

Jenkins, M. J., "Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for Certificates and Certificate Revocation Lists", Work in Progress, Internet-Draft, draft-jenkins-cnsa2-pkix-profile-05, 5 July 2026, <https://datatracker.ietf.org/doc/html/draft-jenkins-cnsa2-pkix-profile-05>.

[I-D.kuehlewind-audit-architecture]

Kühlewind, M. and H. Birkholz, "An Architecture for Auditing Agent Delegation and Interactions", Work in Progress, Internet-Draft, draft-kuehlewind-audit-architecture-01, 7 September 2026, <https://datatracker.ietf.org/doc/html/draft-kuehlewind-audit-architecture-01>.

[I-D.maintainer-1f916-agent-record]

Maintainer, 1., "The Agent Record: Transparent, Witness-Countersigned Event Logs for AI Agent Identity, History, and Memory", Work in Progress, Internet-Draft, draft-maintainer-1f916-agent-record-01, 12 August 2026, <https://datatracker.ietf.org/doc/html/draft-maintainer-1f916-agent-record-01>.

[I-D.mih-scitt-agent-action-capsule]

Mih, S., "An Agent Action Capsule Profile for SCITT", Work in Progress, Internet-Draft, draft-mih-scitt-agent-action-capsule-05, 26 September 2026, <https://datatracker.ietf.org/doc/html/draft-mih-scitt-agent-action-capsule-05>.

[I-D.ni-wimse-ai-agent-identity]

Yuan, N., Liu, P. C., and M. Richardson, "WIMSE Applicability for AI Agents", Work in Progress, Internet-Draft, draft-ni-wimse-ai-agent-identity-03, 30 September 2026, <https://datatracker.ietf.org/doc/html/draft-ni-wimse-ai-agent-identity-03>.

[I-D.noa-scitt-ai-agent-receipt]

Toraman, T., "A SCITT Profile for AI-Agent Action Receipts", Work in Progress, Internet-Draft, draft-noa-scitt-ai-agent-receipt-01, 14 August 2026, <https://datatracker.ietf.org/doc/html/draft-noa-scitt-ai-agent-receipt-01>.

[I-D.novak-rats-tacra]

Novak, M., Richardson, M., and H. Birkholz, "Trustworthy Acquisition of Credentials via Remote Attestation", Work in Progress, Internet-Draft, draft-novak-rats-tacra-01, 11 September 2026, <https://datatracker.ietf.org/doc/html/draft-novak-rats-tacra-01>.

[I-D.palanisamy-scitt-aac-runtime]

Palanisamy, G. and S. Mih, "The model_attestation Block for Agent Action Capsules: Model, Runtime, and Hardware Claims", Work in Progress, Internet-Draft, draft-palanisamy-scitt-aac-runtime-00, 2 October 2026, <https://datatracker.ietf.org/doc/html/draft-palanisamy-scitt-aac-runtime-00>.

[I-D.sharif-apki-agent-pki]

Sharif, R., "Agent Public Key Infrastructure (APKI): Certificate-Based Identity and Trust for Autonomous AI Agents", Work in Progress, Internet-Draft, draft-sharif-apki-agent-pki-01, 27 August 2026, <https://datatracker.ietf.org/doc/html/draft-sharif-apki-agent-pki-01>.

[I-D.sharif-x509-agent-identity-profile]

Sharif, R., "X.509 Certificate Profile for Autonomous AI Agent Identity", Work in Progress, Internet-Draft, draft-sharif-x509-agent-identity-profile-04, 2 October 2026, <https://datatracker.ietf.org/doc/html/draft-sharif-x509-agent-identity-profile-04>.

[I-D.uppalapati-wimse-pq-agent-identity]

Uppalapati, V. K., "Post-Quantum Requirements for Software and AI Agent Identity", Work in Progress, Internet-Draft, draft-uppalapati-wimse-pq-agent-identity-00, 28 September 2026, <https://datatracker.ietf.org/doc/html/draft-uppalapati-wimse-pq-agent-identity-00>.

[RFC5937]

Ashmore, S. and C. Wallace, "Using Trust Anchor Constraints during Certification Path Processing", RFC 5937, DOI 10.17487/RFC5937, August 2010, <https://www.rfc-editor.org/rfc/rfc5937>.

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/rfc/rfc7942>.

[RFC8693]

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/rfc/rfc8693>.

[RFC9162]

Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, <https://www.rfc-editor.org/rfc/rfc9162>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

[RFC9360]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates", RFC 9360, DOI 10.17487/RFC9360, February 2023, <https://www.rfc-editor.org/rfc/rfc9360>.

[RFC9711]

Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, <https://www.rfc-editor.org/rfc/rfc9711>.

[RFC9942]

Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "CBOR Object Signing and Encryption (COSE) Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026, <https://www.rfc-editor.org/rfc/rfc9942>.

[RFC9943]

Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, <https://www.rfc-editor.org/rfc/rfc9943>.

[RFC9964]

Prorock, M. and O. Steele, "ML-DSA for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)", RFC 9964, DOI 10.17487/RFC9964, May 2026, <https://www.rfc-editor.org/rfc/rfc9964>.

[TLOG-WITNESS]

C2SP, "Transparency Log Witness Protocol", October 2026, <https://c2sp.org/tlog-witness@v1.1.0>.

B.1. Agent Sponsor

{
  sponsor { uniformResourceIdentifier :
    "urn:example:org:EX:business-register:00000000" },
  capacity "authorised signatory",
  mandate "https://mandates.example/m/0001"
}

3068302f862d75726e3a6578616d706c653a6f72673a45583a627573696e6573
732d72656769737465723a30303030303030308014617574686f726973656420
7369676e61746f7279811f68747470733a2f2f6d616e64617465732e6578616d
706c652f6d2f30303031

B.2. Declared Scopes

{ "repository:read", "ci:run" }

30190c0f7265706f7369746f72793a726561640c0663693a72756e

B.3. Agent Configuration

Each component carries a SHA-256 digest. For reproducibility, the digests in this example are computed over short ASCII strings standing in for real inputs: "example-model weights v1" (24 octets) for the model and "example-runtime 2.4.1 evidence" (30 octets) for the runtime. A real deployment would digest the component, or the evidence, in a form its deployment profile defines. The runtime component is marked attested; its reference locates the attestation evidence the CA appraised, and its digest covers that evidence, so a relying party can check that what it retrieves is what the CA appraised.¶

{
  { role "model", name "example-model", version "2026-09",
    digest { algorithm { algorithm id-sha256 },
             value '81D5A8E7BA7EC798C3E0B85A90644581
                    607E770A5FC033EE95988BC0F5E603BD'H },
    source declared },
  { role "runtime", name "example-runtime", version "2.4.1",
    digest { algorithm { algorithm id-sha256 },
             value '2A7F4808842ACDF0BC73041939A1EC76
                    75E11CB016AD5DC4CCE267F1711F670E'H },
    reference "https://ca.example/evidence/rt-2.4.1",
    source attested }
}

3081d230530c056d6f64656c800d6578616d706c652d6d6f64656c8107
323032362d3039a22f300b0609608648016503040201042081d5a8e7ba
7ec798c3e0b85a90644581607e770a5fc033ee95988bc0f5e603bd0a01
00307b0c0772756e74696d65800f6578616d706c652d72756e74696d65
8105322e342e31a22f300b060960864801650304020104202a7f480884
2acdf0bc73041939a1ec7675e11cb016ad5dc4cce267f1711f670e8324
68747470733a2f2f63612e6578616d706c652f65766964656e63652f72
742d322e342e310a0102

C.1. The agent

The SHA-256 hash of the DER encoding of the SubjectPublicKeyInfo (1974 octets) is:¶

8378eefb86a7ae09491f838f772409c07dbf1d47b95a37d75582a86ac1742155

C.2. The TBSCertificateLogEntry

The DER encoding (463 octets) is:¶

308201cba00302010230143112301006082b060105050719030d0481fd590130
1e170d3236313031393030303030305a170d3236313032363030303030305a30
00300b060960864801650304031204208378eefb86a7ae09491f838f772409c0
7dbf1d47b95a37d75582a86ac1742155a382015b3082015730490603551d1101
01ff043f303d863b77696d73653a2f2f782d726f61642e6578616d706c652f45
582f425553494e4553532f30303030303030302f7265706f7274696e672d6167
656e743078060a2b0601040181fd590201046a3068302f862d75726e3a657861
6d706c653a6f72673a45583a627573696e6573732d72656769737465723a3030
3030303030308014617574686f7269736564207369676e61746f7279811f6874
7470733a2f2f6d616e64617465732e6578616d706c652f6d2f30303031302906
0a2b0601040181fd590202041b30190c0f7265706f7369746f72793a72656164
0c0663693a72756e3065060a2b0601040181fd5902030457305530530c056d6f
64656c800d6578616d706c652d6d6f64656c8107323032362d3039a22f300b06
09608648016503040201042081d5a8e7ba7ec798c3e0b85a90644581607e770a
5fc033ee95988bc0f5e603bd0a0100

C.3. The log entry and its hash

The MTCLogEntry (Section 5.2.1 of [I-D.ietf-plants-merkle-tree-certs]) has an empty extensions vector, encoded as the two octets 0000, then the type tbs_cert_entry, encoded as the two octets 0001, then tbs_cert_entry_data, which is the TBSCertificateLogEntry above without its outer SEQUENCE tag and length octets (the 459 content octets). Its length is 463 octets and it begins 00000001a003020102. The entry hash is the SHA-256 hash of the octet 0x00 followed by the entry:¶

468ab8db011397a80e1ddb90c453b13c9e1fe45b298abe31cae78acfd24df328

C.4. A four-entry log

The agent entry is at index 2 of a log whose other entries are of type null_entry or carry only entry extensions. Their entries and entry hashes are:¶

index 0: entry 00000000
  hash 8855508aade16ec573d21e6a485dfd0a
       7624085c1a14b5ecdd6485de0c6839a4
index 1: entry 0006fffe000276310000
  hash 898ea43418e3bcff15bf71a8749e8281
       95e2859e8f08fd0640dd7a203f725364
index 2: the agent entry
  hash 468ab8db011397a80e1ddb90c453b13c
       9e1fe45b298abe31cae78acfd24df328
index 3: entry 000bfffd000101fffe000276320000
  hash 817e15fbba33ce5f1a4967a13e575c23
       74dd11d177c252cddeecd61ddc0add41

The hash of the subtree [0, 4), computed with the tree construction of Section 2.1.1 of [RFC9162] as Section 4.1 of [I-D.ietf-plants-merkle-tree-certs] specifies, is:¶

fa661a3b95b11960dc96f238eb796310332bc025d7252e82ba322e41305fe0cf

The subtree inclusion proof for the agent entry (index 2) in [0, 4) consists of the hash of entry 3, then the hash of the node over entries 0 and 1:¶

817e15fbba33ce5f1a4967a13e575c2374dd11d177c252cddeecd61ddc0add41
69b3db98de9c17f68b3afc75f3c46408e6a5430ee120de47cccc60a992457f04

Concatenated, as they appear in MTCProof.inclusion_proof, they form 64 octets.¶

C.5. Certificate serial number and the signed message

If the log has log number 1, the serial number of the certificate for the agent entry is (1 << 48) | 2 = 281474976710658 (0x1000000000002), DER 020701000000000002.¶

A cosigner with cosigner ID 32473.3 signing this subtree for the issuance log with ID 32473.1.0.1 signs the following CosignedSubtree (Section 5.3.1 of [I-D.ietf-plants-merkle-tree-certs]), 120 octets, with timestamp zero, start 0 and end 4:¶

737562747265652f76310a00176f69642f312e332e362e312e342e312e333234
37332e3300000000000000001b6f69642f312e332e362e312e342e312e333234
37332e312e302e3100000000000000000000000000000004fa661a3b95b11960
dc96f238eb796310332bc025d7252e82ba322e41305fe0cf