Agent Name Service v2 (ANS): A Domain-Anchored Trust Layer for Autonomous AI Agent Identity

1.1. Motivating Scenario

Consider a concrete failure mode. A company's payment agent receives an instruction to wire $50,000 to a supplier's invoicing agent. The invoicing agent presents a website URL secured by a TLS certificate. The payment agent must decide: does this agent actually belong to the supplier, or has someone stood up a convincing fake?¶

An attacker registers a look-alike domain such as payments-supplier.example.com and presents a valid TLS certificate for it. The payment agent has no way to tell this impostor from the real supplier, because a Domain Validation (DV) certificate -- the most common type -- proves only that someone controls the domain, not that the domain belongs to the right organization. Organization Validation (OV) and Extended Validation (EV) certificates exist but are rarely used for programmatic agent endpoints.¶

Separately, a legitimate supplier may pass a security audit and then quietly update its model. The certificate stays valid, the endpoint stays up, but the code behind it is no longer what was audited.¶

1.2. Origin and Evolution

This document builds on "Agent Name Service (ANS): A Universal Directory for Secure AI Agent Discovery and Interoperability" [ANSv1], published at IEEE ICAIC 2026 and contributed to the IETF as an Internet-Draft. The original paper proposed a conceptual architecture with a six-component ANSName format. The architecture presented here simplifies the ANSName to three components (ans://v{version}.{agentHost}), introduces a dual-certificate model, replaces conceptual registry integrity with a cryptographic Transparency Log, moves protocol adapters to a client SDK, and decouples discovery from the RA.¶

1.3. Relationship to Other Standards

HCS-14 [HCS14] uses DNS TXT records for agent discovery; an ANS Profile for HCS-14 allows any HCS-14 resolver to discover ANS agents. HCS-27 [HCS27] defines a checkpoint format for publishing the Transparency Log's root hash to a distributed consensus topic. The IETF SCITT working group [I-D.ietf-scitt-architecture] defines an append-only transparency service; the ANS TL follows this model. DNS-AID [DNSAID] uses SVCB service binding records [RFC9460] for agent endpoint discovery; DNS-AID tells a client where to connect, ANS tells it whether to trust the agent.¶

1.4. Regulatory Context

Regulators are converging on verifiable agent identity as a compliance requirement. The EU AI Act (Article 50) requires transparency and identity disclosure for AI systems that interact with people. In the US, NIST's Center for AI Standards and Innovation solicited public input on securing AI agent systems in early 2026. Both point toward mandatory verifiable agent identity.¶

1.5. Foundational Principles

Every agent maps to a unique, globally resolvable Fully Qualified Domain Name (FQDN). The ANSName format ans://v{version}.{agentHost} embeds the FQDN directly. The domain is the agent's permanent address; the version number changes, the domain does not.¶

Five design decisions follow from this foundation:¶

1. Domain control validation: The RA verifies ownership using the ACME protocol [RFC8555] (DNS-01 or HTTP-01 challenges) before attesting to any identity.¶
2. Decentralized discovery: The TL publishes sealed lifecycle events. Third-party Discovery Services subscribe, verify signatures, and build their own indexes.¶
3. Version-bound lifecycle: Every change to an agent's software or capabilities requires a new version number and a new registration.¶
4. Dual-certificate model: A Server Certificate from a public CA secures the stable FQDN. An Identity Certificate from a private CA attests to the version-bound ANSName.¶
5. Discoverable schemas: The ANS Trust Card links each protocol to a canonical URL. Schemas are public, versioned artifacts.¶

1.6. Registration Progression

The RA acts as a notary. It witnesses domain control, issues certificates, specifies DNS records, and seals the event into the TL. The minimum registration is intentionally low: a domain, a version, at least one endpoint, and an identity CSR.¶

1.7. Open Protocol Design

The protocol is designed for an open, federated market. Any organization can operate an RA, a TL, a Trust Index, or a Discovery Service. Multiple RAs can coexist, each issuing certificates and sealing events into its own TL. Multiple Trust Index providers can crawl the same logs and produce competing evaluations. Every interface is public. The DNS record types are standard. The TL verification API uses REST. The certificate model uses ACME, which any server can answer.¶

1.8. Conformance Roles

The protocol defines five roles:¶

Registration Authority:

Validates domain control via ACME, issues Identity Certificates from a Private CA, obtains or accepts Server Certificates from a Public CA, generates DNS record content, and submits lifecycle events to a TL.¶

Discovery Service:

Consumes RA output and indexes agents. Any DNS provider, search engine, or marketplace can operate one.¶

Transparency Log operator:

Seals signed events into an append-only cryptographic structure, signs checkpoints, and exposes a public verification API. A conforming TL operates as a SCITT Transparency Service [I-D.ietf-scitt-architecture].¶

Trust Index provider:

Crawls TL events from one or more federated RAs and publishes evaluations as signed Verifiable Credentials.¶

Verifier:

A client that checks an agent's identity before connecting. Verification is a client-side act, not a property the RA assigns. The verifier needs no relationship with the RA.¶

4.1. Registration Authority System

The RA system comprises:¶

Registration Authority (RA):

Receives registration requests from AHPs, validates domain control via ACME [RFC8555], requests an Identity Certificate from the Private CA, obtains a Server Certificate from the Public CA (or accepts one the AHP brings), generates DNS records, and seals the registration into the TL.¶

Key Management System (KMS):

Signs every TL checkpoint. If this key is compromised, every sealed record in the log becomes untrustworthy.¶

Provider Registry:

Decouples an entity's legal name from its identifier. When "AcmeCorp" becomes "MegaCorp," one record updates instead of re-registering thousands of agents.¶

Agent Integrity Monitor (AIM):

Compares the live internet against what the RA sealed. When something does not match, it publishes a finding. It cannot revoke certificates or command state changes.¶

RA API:

The AHP registers an agent, submits CSRs for both certificate types, and triggers ACME and DNS verification. Agent discovery flows from the Event Stream through independent indexing services, not through the RA.¶

4.2. Agent Hosting Platform System

The AHP hosts the agent's code and serves the live endpoints at the agent's FQDN. The AHP may also host an ANS Trust Card; the Trust Index rewards its presence. During registration, the AHP responds to ACME challenges so the RA can verify domain control, then receives both certificates and installs them in its keystore. The AHP provisions DNS records using content the RA generates. When the agent's code changes, the AHP initiates a new version registration.¶

Interfaces hosted by the AHP include the Agent Functional Endpoint (the live service exposing capabilities) and the ANS Trust Card (the metadata document describing capabilities, endpoints, supported protocols, and ANS trust fields).¶

4.3. Transparency Log

The TL receives signed events from the RA, validates each signature, and seals the events into a cryptographic append-only structure. That structure produces two kinds of proof: inclusion proofs (proving a specific event exists in the log) and consistency proofs (proving the log has only grown, never shrunk or rewritten). The KMS signs each checkpoint. A conforming TL MUST operate as a SCITT Transparency Service [I-D.ietf-scitt-architecture], issuing binary COSE receipts as proof of inclusion.¶

Each event receives a sequence number that increases with every entry and never repeats. Events become visible only after the KMS signs a checkpoint, so a client querying the log always sees a consistent, finalized view. Each event carries a schema version so that field renames in future schemas do not break existing consumers.¶

A conforming TL MUST expose a REST API for external verifiers:¶

The TL MUST distribute verification keys via /root-keys so that any verifier can check root signatures without contacting the RA. Verification MUST NOT require access to producer public keys, authentication for read-only operations, or knowledge of RA implementation details.¶

4.4. Event Stream

The Event Stream makes sealed events queryable. Every payload carries the RA's signature, verifiable against keys the RA registered at the TL. Consumers verify authenticity without contacting the TL. Discovery Services subscribe to the Event Stream to build searchable indexes.¶

4.5. Certificate Authorities

Two CAs, two trust roots, two revocation paths:¶

• Public CA: Issues Server Certificates. Revocation propagates through public OCSP/CRL [RFC6960].¶
• Private CA: Issues Identity Certificates on the RA's behalf. The RA requests issuance; the Private CA signs. The Private CA may be operated by the RA operator or by a separate organization. The Identity Certificate requires a URI SAN that no Public CA can issue. Only a Private CA, operating under its own issuance policy and certificate practice statement, can include the ans:// scheme. The Identity Certificate's validity period is not subject to CA/Browser Forum Baseline Requirements constraints.¶

4.6. DNS Provider

The external service that hosts the agent's DNS zone. The RA generates DNS record content; the AHP provisions it at the DNS provider.¶

4.7. Trust Framework: Three Layers

The RA answers one question: "Who are you?" It does not evaluate whether the agent is well-governed or well-behaved. Three layers of trust data together provide a complete answer.¶

Layer 1: Foundational identity (this protocol).

The RA verifies domain control, issues certificates, and seals the Registration Metadata hash into the Transparency Log. This layer is the scope of this document.¶

Layer 2: Operational maturity (third-party attestors).

SOC 2 reports, HIPAA compliance certificates, and SBOMs arrive as references in the Trust Card's verifiableClaims array. They update on the attestor's cycle: annually for an audit, quarterly for a compliance scan.¶

Layer 3: Behavioral reputation (real-time scoring).

Transaction records, settlement rates, and dispute flags. While these signals may go back months, they update in seconds.¶

No single source controls the evaluation. A companion Trust Index specification defines how a provider consumes sealed data from Layer 1 and external signals from Layers 2 and 3, computes a multi-dimensional trust evaluation, and returns it as a signed credential that clients use for authorization decisions.¶

4.8. The ANS SDK

The version-bound lifecycle requires a new registration on every code change. Without tooling, a developer who ships a one-line fix must also generate a key pair, build a CSR, submit it to the RA, wait for domain validation, install the new certificate, and update DNS. The SDK collapses that sequence into a single command.¶

The SDK contains a Protocol Adapter Layer that translates Protocol Cards (A2A Agent Cards, MCP manifests, OpenAPI documents) into the RA's registration payload format. This is a key architectural departure from the original ANS proposal [ANSv1], where protocol adapters resided within the RA. Moving adapters to the client side means the RA accepts a single payload format regardless of protocol, simplifying its implementation and reducing its attack surface.¶

The SDK also bundles a Trust Provisioner that manages the agent's trust store. In the single-RA phase, it installs the bootstrapping RA's Private CA root certificate. In the federated phase, it retrieves a trust bundle from the Federation Registry containing root certificates of all compliant RAs.¶

5.1. The ANSName

The canonical identifier for a registered agent has three components ([RFC1035], [RFC1123]):¶

ANSName = "ans://v" version "." agentHost
version = 1*DIGIT "." 1*DIGIT "." 1*DIGIT
agentHost = <FQDN per RFC 1035 and RFC 1123>

Example: ans://v1.0.0.sentiment-analyzer.example.com¶

The 237-octet host limit: The RA derives DNS record names by prepending labels to the agentHost. The longest derived name is _acme-challenge.{agentHost}, consuming 17 octets (16 characters plus the label separator) of the 253-octet presentation-format domain name limit (RFC 1035 Section 2.3.4, RFC 1123 Section 2.1). 253 - 16 = 237.¶

The complete ANSName MUST NOT exceed 400 octets, providing headroom for safe transport across HTTP headers, TLS fields, and database columns.¶

Two metadata fields accompany the ANSName at registration but are not part of the identifier: agentDisplayName (required, max 64 characters, human-readable label for discovery UIs) and agentDescription (optional, max 150 characters).¶

5.2. Identifier Taxonomy

5.3. Three Agent Card Terms

1. Protocol Card: The protocol-native metadata file (A2A Agent Card, MCP manifest, OpenAPI document). Created by the developer.¶
2. Registration Metadata: The agentCardContent field in the registration payload. The SDK translates the Protocol Card into this format. The RA hashes it and seals the hash into the TL.¶
3. ANS Trust Card: An optional COSE_Sign1 document the AHP hosts at /.well-known/ans/trust-card.json. Contains protocol-native metadata augmented with ANS trust fields (ANSName, verifiable claims, trust references) and a stapled SCITT receipt. The AIM verifies the content hash against the value sealed when Registration Metadata is submitted.¶

5.4. Certificate Integrity

The Identity Certificate requires a URI SAN. The ans:// scheme is syntactically valid per RFC 3986 [RFC3986] Section 3.1 and permitted in URI SANs per RFC 5280 [RFC5280] Section 4.2.1.6. CA/Browser Forum Baseline Requirements prohibit URI SANs in publicly trusted server certificates (BR Section 7.1.2.7.12). A Public CA cannot issue this certificate; only a Private CA can.¶

5.5. Agent State Lifecycle

The RA tracks registration state in its database. Only certain transitions produce TL events: entering ACTIVE, DEPRECATED, REVOKED, or EXPIRED, and renewal while ACTIVE (the AGENT_RENEWED event type). RENEWED is a TL event type, not a distinct registration state; the agent remains ACTIVE throughout the renewal process. Transitions before activation (PENDING to PENDING_DNS) are RA-internal.¶

External domains pass through PENDING_DNS; internal domains with automated DNS skip directly to ACTIVE. Revocation is idempotent. Cancellation before activation produces no TL event because the log-sealing step has not occurred.¶

5.6. Cryptographic Data Integrity Standards

Every signature MUST include protected headers: alg (signing algorithm), kid (key identifier), typ (type indicator), timestamp (Unix timestamp), and raId (RA instance identifier). All JSON payloads MUST be canonicalized per JCS [RFC8785] before signing. Signatures use JWS Compact Serialization [RFC7515] with the JSON data interchange format [RFC8259].¶

6.1. Layered Trust and Verification Tiers

Trust rests on three independent verification dimensions (distinct from the three-layer trust data framework in Section 4.7, which separates data sources):¶

A client verifies an agent through independent checks, each using a different trust channel:¶

A tier describes what the client verified, not a property the RA assigned. Two clients connecting to the same agent may reach different tiers depending on what checks they run.¶

TLSA parameters: The RA specifies TLSA 3 0 1 [sha256_hash]: DANE-EE (usage 3), full Server Certificate (selector 0), SHA-256 (matching type 1) [RFC6698]. Selector 0 produces the same hash as the badge fingerprint in the TL, so a single SHA-256 computation serves both DANE and badge verification.¶

DANE requires DNSSEC [RFC4033]. Per RFC 6698 Section 4, a TLSA RRset whose DNSSEC validation state is not "secure" MUST be treated as unusable, and the client falls back to standard PKIX certificate validation. The RA SHOULD verify DNSSEC status before provisioning TLSA records.¶

6.2. DNS Trust Anchor

The RA specifies one _ans-badge TXT record per ACTIVE version, pointing to that version's badge in the TL. The AHP provisions it.¶

_ans-badge.{agentHost} IN TXT
  "v=ans-badge1; version=v1.0.0;
   url=https://{tl_host}/v1/agents/{agentId}"

When multiple versions are ACTIVE, each has its own _ans-badge record. A verifier that knows the version (from the Identity Certificate's URI SAN) selects the matching record.¶

6.3. Cryptographic Verification Path

High-assurance verification walks this chain:¶

1. Verify the _ans-badge TXT record via DNSSEC.¶
2. Validate the JWS signature on the attestation badge using the RA's public key.¶
3. Verify that the event exists in the TL via an inclusion proof.¶
4. Validate the Signed Tree Head using the KMS key identifier.¶
5. Confirm the agent's current state matches the latest log entry.¶

6.4. Mutual TLS Between ANS-Registered Agents

The mTLS handshake proceeds as follows:¶

1. Caller sends ClientHello.¶
2. Server returns Server Certificate + CertificateRequest.¶
3. Caller presents its Identity Certificate.¶
4. Server verifies the caller's Identity Certificate against the ANS Private CA.¶
5. mTLS tunnel established. The caller knows the server's FQDN; the server knows the caller's ANSName.¶
6. Caller verifies the server's versioned identity via _ans-badge TXT record or TL query.¶

Steps 1-5 are standard mTLS. Step 6 is ANS-specific: the caller confirms the server's Server Certificate fingerprint matches the badge the RA sealed at registration.¶

When the agent's ANS Trust Card carries a stapled SCITT receipt, the caller verifies locally with no TL call. When the Trust Card is absent, the caller fetches the receipt from the _ans-badge URL. If the TL is unreachable, the caller falls back to PKI + DANE verification and records the downgrade.¶

When an agent acts on behalf of a human, the agent proves its own identity via mTLS. The human's authorization travels separately as a delegation token [RFC8693].¶

6.5. Key Management

The RA never generates, handles, or accesses an agent's private keys. The AHP owns its key lifecycle. The RA uses separate credentials for each external service integration, rotated on schedule.¶

Each RA instance MUST register at least one active public key with the TL before submitting events. Rotation uses an overlap window: new keys are registered with future validFrom dates; both old and new remain active during the transition. Producer private keys never leave the RA instance. Historical signatures remain valid after key expiration but not after revocation.¶

6.6. Channel vs. Message-Level Security

TLS secures transient, point-to-point API calls. Digital signatures secure durable artifacts that third parties or asynchronous consumers verify independently.¶

6.7. Privacy Considerations

Query privacy is out of scope for the RA. Discovery Services SHOULD implement privacy-preserving techniques (Private Information Retrieval, Anonymized Query Relays).¶

The TLS handshake reveals the agent's hostname to network observers. Encrypted Client Hello (ECH, RFC 9849) [RFC9849] encrypts the inner ClientHello, hiding the hostname and other connection parameters such as the ALPN list. When an AHP provides an ECH configuration during registration, the RA publishes it in the HTTPS record.¶

7.1. Initial Registration Flow

Registration has two stages:¶

1. AHP submits registration request.¶
2. RA validates domain control (ACME) [RFC8555].¶
3. RA obtains Server + Identity Certificates.¶
4. RA seals event into TL. (Point of no return.)¶
5. RA returns certificates + DNS record content to AHP.¶
6. AHP provisions DNS.¶

7.2. Lifecycle Operations

During a version bump, both old and new versions are ACTIVE. The Server Certificate stays active (tied to the FQDN, not the version). The RA does not impose a retirement timeline.¶

Rollbacks: The AHP deploys the old stable code as a new version (e.g., v1.0.2), registers it, and revokes the buggy version.¶

7.3. DNS Management Roles

A CNAME at the agent's FQDN blocks HTTPS and SVCB records at the same label (RFC 1034 Section 3.6.2) but does not affect child-label records (_ans, _ans-badge, _443._tcp). When the RA detects a CNAME, it skips the HTTPS record. CNAME flattening by the DNS provider can mitigate this restriction.¶

7.4. DNS Record Set

The RA generates record content for child labels under the agent's FQDN. The AHP or domain owner provisions the records:¶

_ans.{agentHost} IN TXT
  "v=ans1; version=v1.0.0; p=a2a;
   url=https://agent.example.com/.well-known/agent-card.json"

7.5. Coexistence with DNS-AID

A domain owner can publish DNS-AID SVCB records [DNSAID] [RFC9460] alongside _ans TXT records. The two record families occupy different DNS names and do not collide. An ANS-aware client reads _ans; a DNS-AID client reads the SVCB records under _agents.¶

7.6. Ongoing Integrity Verification

An AIM MUST distinguish between "Unreachable" (transient network failure, retry later) and "Mismatch" (the content has changed, remediation needed).¶

8.1. HCS-14 ANS Profile

Hiero's HCS-14 standard [HCS14] independently arrived at DNS TXT records for agent discovery, using _agent.<nativeId> as the record name. An ANS Profile within HCS-14 allows resolvers to verify ANS DNS records, certificates, and log proofs through a standard interface without ANS-specific branching.¶

8.2. HCS-27 Merkle Tree Checkpoint

A companion specification [HCS27] defines a checkpoint format for publishing the TL's root hash to a distributed consensus topic. The timestamp on the consensus topic is independently verifiable, strengthening the guarantee that historical log entries have not been backdated or rewritten.¶

8.3. IETF SCITT Alignment

The SCITT architecture [I-D.ietf-scitt-architecture] defines an append-only transparency service that accepts signed statements, registers them, and returns receipts. The ANS TL follows this model. A future goal is formal SCITT compliance, adopting COSE (RFC 9052) [RFC9052] signed statements and standardized receipt formats for interoperability with other SCITT-compliant transparency services.¶

8.4. Deployment Topologies

The same RA, TL, and certificate infrastructure can run at different scopes:¶

• Public ANS: The RA, TL, and event feeds are internet-facing. Any verifier that has installed the Private CA root can verify any agent's identity and audit its history.¶
• Internal ANS: An organization runs its own RA and TL behind its corporate network. Agents are visible only to participants on that network.¶
• Enterprise ANS as a service: A hosted internal ANS instance, operated on behalf of an enterprise in their own cloud account.¶
• Extranet ANS: A semi-private deployment shared among a defined set of partner organizations.¶

Each topology runs the same protocol. The difference is who can see the TL, who can query the event feeds, and who controls the Private CA.¶

9.1. Two-Layer Proof Composition

A sealed event carries two independent proofs of existence, each anchored to a different trust root.¶

Layer 1 (Transparency Log): Let E be a lifecycle event sealed at leaf index i in a log of size n with Merkle root R. An inclusion proof consists of a hash path of length ceil(log2(n)). The proof is valid iff recomputing the root from LeafHash(E), the path, and i yields R, and the signature over R verifies against the TL's published KMS key. Implementations targeting SCITT compliance [I-D.ietf-scitt-architecture] encode the proof as a COSE_Sign1 receipt; the verification semantics are identical.¶

Layer 2 (Consensus Checkpoint): An HCS-27 checkpoint [HCS27] publishes R to a distributed consensus topic at timestamp T. The topic provides an independently verifiable total ordering.¶

Together, the two layers guarantee:¶

1. Inclusion: If a receipt for event E verifies against root R, then E was sealed into the log before the checkpoint containing R.¶
2. Non-repudiation: Removing E from the log after checkpoint publication requires producing a tree of size n' >= n whose root R' is consistent with R yet excludes leaf i. This contradicts the collision resistance of SHA-256.¶
3. Temporal binding: Because the consensus topic provides an independently verifiable timestamp, the TL operator cannot backdate an event.¶

An attacker who compromises the KMS alone can sign fraudulent roots, but cannot insert those roots into the consensus topic's history. An attacker who compromises the consensus topic alone cannot produce valid inclusion proofs. Both channels must be compromised simultaneously to forge a sealed event with a credible timestamp.¶

9.2. Cryptographic Boundary Enforcement

The protocol distributes trust across four services. No service accepts another's assertions without verifying a cryptographic signature.¶

Compromise of any single component is detectable by the others. A compromised RA instance can sign fraudulent events, but every event records the instance's raId; an auditor isolates the damage. A compromised TL can sign fraudulent checkpoints, but cannot retroactively alter checkpoints already published to the HCS-27 consensus topic. A compromised AIM can file false reports, but the RA re-verifies each finding; the quorum requirement prevents a single monitor from triggering remediation. A compromised Event Stream can suppress or delay events, but cannot forge new ones.¶

This property does not hold against collusion between the RA and TL operators. HCS-27 consensus checkpoints and federation (Section 8.4) provide the primary mitigations.¶

10.1. Failure Modes

12.1. Agent Impersonation

Risk: An adversary impersonates a legitimate agent. Mitigation: Mandatory PKI with dual certificates. The Identity Certificate binds a specific code version to a verified domain. The agent must prove possession of the private key. Certificate chain validation against the Private CA root.¶

12.2. Registry Poisoning

Risk: An adversary injects malicious data (corrupted capabilities or endpoints) into the registry. Mitigation: The Transparency Log makes all sealed entries immutable and tamper-evident. The RA validates all payloads before sealing. The AIM continuously compares live DNS and Trust Card state against the TL's sealed records.¶

12.3. Man-in-the-Middle

Risk: An adversary modifies communications between system components. Mitigation: Message integrity via digital signatures (JWS Detached). mTLS between ANS-registered agents using Identity Certificates. DANE provides a second trust channel independent of the CA system.¶

12.4. Denial of Service

Risk: Adversary incapacitates RA, TL, or resolution services. Mitigation: The data plane (mTLS handshakes between agents) continues during RA or AIM outages. Previously established trust proofs remain valid until certificates expire. Standard operational defenses (rate limiting, DDoS protection).¶

12.5. Transparency Log Compromise

Risk: An adversary modifies or deletes historical TL entries. Mitigation: Merkle tree structure makes tampering mathematically detectable via consistency proofs between any two tree states. KMS key separation ensures the signing key does not reside on the TL host. HCS-27 checkpoint anchoring to a public distributed ledger provides independently verifiable timestamps.¶

12.6. Compromised RA Instance

Risk: A single RA instance is breached and issues fraudulent registrations. Mitigation: Every TL entry records the raId of the processing instance. Auditors isolate every event that instance touched. Separation of duties requires the RA's DNS permissions exclude TLSA write access, preventing a compromised RA from also forging DANE records.¶

12.7. SDK Supply Chain Compromise

Risk: The SDK manages key generation, CSR submission, and Trust Card assembly. A compromised SDK could exfiltrate private keys or submit altered registration payloads. Mitigation: The SDK is open-source and auditable. Key generation uses platform cryptography (HSM, TPM, or OS keystore when available). The RA validates every CSR and registration payload independently. Software signing and provenance attestation (e.g., SLSA, Sigstore) reduce the risk of tampered distributions.¶

12.8. Single Operator Risk

For a given registration, the same entity may operate both the RA and the TL that seals it. If that entity is compromised, it could forge events with no independent check. HCS-27 consensus checkpoints are the primary mitigation: the TL's root hash is anchored to an independently verifiable ledger that neither the RA nor the TL controls. Federation adds a second layer: an agent can register with an RA operated by one entity and have events sealed by a TL operated by another.¶

12.9. Ecosystem Integrity and Remediation

Four principles guard against malicious monitoring services:¶

1. Monitors report, the RA acts: External monitors publish findings. They cannot command state changes.¶
2. Reports are public and signed: Monitors publish to cryptographically signed feeds, building verifiable reputation.¶
3. Quorum before action: The RA MUST NOT act on a single report from one monitor.¶
4. Evidence must be verifiable: Every finding MUST include cryptographic proof. The RA re-verifies independently.¶

Suppression before revocation: When a finding meets the quorum requirement, the RA independently re-verifies the reported mismatch against the TL's sealed records. If confirmed, the RA publishes a suppression event to the TL. Discovery services that consume the event feed remove the agent from their indexes. Suppression is reversible; revocation is permanent.¶

A.1. Registration Request

The AHP submits this payload to the RA's /register endpoint.¶

{
  "agentDisplayName": "Acme Support Agent",
  "agentDescription": "Customer support agent.",
  "version": "1.5.0",
  "agentHost": "support.example.com",
  "endpoints": [
    {
      "protocol": "A2A",
      "agentUrl": "wss://support.example.com/a2a",
      "metadataUrl":
        "https://support.example.com/.well-known/agent-card.json",
      "transports": ["STREAMABLE-HTTP", "SSE"],
      "functions": [
        { "id": "lookupOrder", "name": "Lookup Order",
          "tags": ["order", "support"] }
      ]
    },
    {
      "protocol": "MCP",
      "agentUrl": "https://support.example.com/mcp",
      "metadataUrl":
        "https://support.example.com/.well-known/mcp/
        server-card.json",
      "transports": ["STREAMABLE-HTTP"],
      "functions": [
        { "id": "getTicketStatus", "name": "Get Ticket Status",
          "tags": ["ticket", "support"] }
      ]
    }
  ],
  "identityCsrPEM": "...(truncated)...",
  "serverCsrPEM": "...(truncated)...",
  "lei": "549300EXAMPLE00LEI17",
  "agentCardContent": { "...see A.2..." }
}

A.2. ANS Trust Card

Hosted by the AHP at the URL advertised in the _ans DNS record. Built from the Protocol Card, augmented with ANS trust fields. This artifact is optional.¶

{
  "ansName": "ans://v1.5.0.support.example.com",
  "agentDisplayName": "Acme Support Agent",
  "version": "1.5.0",
  "agentHost": "support.example.com",
  "releaseChannel": "stable",
  "endpoints": [
    {
      "protocol": "A2A",
      "agentUrl": "wss://support.example.com/a2a",
      "metadataUrl":
        "https://support.example.com/.well-known/agent-card.json",
      "transports": ["STREAMABLE-HTTP", "SSE"],
      "functions": [
        { "id": "lookupOrder", "name": "Lookup Order",
          "tags": ["order", "support"] }
      ]
    }
  ],
  "securitySchemes": {
    "agentAuth": {
      "type": "mutual_tls",
      "description": "mTLS using the agent's Identity Certificate."
    }
  },
  "verifiableClaims": [
    {
      "type": "SOC2_TYPE2",
      "issuer": "did:web:auditor.example.com",
      "hash": "SHA256:9f3a2b...",
      "url":
        "https://auditor.example.com/reports/example-2026.json",
      "issuedAt": "2026-01-15T00:00:00Z",
      "expiresAt": "2027-01-15T00:00:00Z"
    },
    {
      "type": "SBOM_CYCLONEDX",
      "issuer": "self",
      "hash": "SHA256:4e7d1c...",
      "url":
        "https://support.example.com/.well-known/sbom.json",
      "issuedAt": "2026-02-01T00:00:00Z"
    }
  ]
}

A.3. TL Event Payload

{
  "ansId": "550e8400-e29b-41d4-a716-446655440000",
  "ansName": "ans://v1.5.0.support.example.com",
  "eventType": "AGENT_REGISTERED",
  "agent": {
    "host": "support.example.com",
    "name": "Acme Support Agent",
    "version": "v1.5.0",
    "providerId": "PID-8294",
    "lei": "549300EXAMPLE00LEI17"
  },
  "attestations": {
    "identityCert": {
      "fingerprint": "SHA256:22b8a804...",
      "type": "X509-OV-CLIENT"
    },
    "serverCert": {
      "fingerprint": "SHA256:d2b71bc0...",
      "type": "X509-DV-SERVER"
    },
    "dnsRecordsProvisioned": {
      "_ans": "v=ans1; version=v1.5.0; ...",
      "_ans-badge": "v=ans-badge1; version=v1.5.0; ..."
    },
    "domainValidation": "ACME-DNS-01",
    "dnssecStatus": "fully_validated"
  },
  "expiresAt": "2026-10-05T18:00:00.000000Z",
  "issuedAt": "2026-03-05T18:00:00.000000Z",
  "raId": "id-A",
  "timestamp": "2026-03-05T18:00:00.000000Z"
}

A.4. TL Badge Response

Badge consumers query GET /v1/agents/{agentId}.¶

{
  "schemaVersion": "V1",
  "status": "ACTIVE",
  "payload": {
    "logId": "550e8400-e29b-41d4-a716-446655440000",
    "producer": {
      "event": { "...same structure as A.3..." },
      "keyId": "id-B",
      "signature": "eyJhbGciOiJFUzI1NiJ9..."
    }
  },
  "signature": "eyJhbGciOiJFUzI1NiIsImtpZCI6...",
  "inclusionProof": {
    "leafHash": "abc123def456...",
    "leafIndex": 1234567,
    "treeSize": 9876543,
    "treeVersion": 1,
    "path": ["def456789abc...", "012345abcdef...", "..."],
    "rootHash": "current1234abcdef...",
    "rootSignature": "eyJhbGciOiJFUzI1NiJ9..."
  }
}

The path array contains log2(treeSize) hashes: about 30 for a billion events (under 1 KB).¶

A.5. DNS Records

$ORIGIN support.example.com.
$TTL 3600

; Core Location Records (Managed by AHP)
@       IN  A      192.0.2.50
@       IN  AAAA   2001:db8::50

; RA generates; AHP provisions
@            IN  HTTPS  1 . alpn="h2"
_443._tcp    IN  TLSA   3 0 1 <sha256_of_server_cert>

_ans         IN  TXT    "v=ans1; version=v1.5.0; p=a2a;
    url=https://support.example.com/.well-known/agent-card.json"
_ans         IN  TXT    "v=ans1; version=v1.5.0; p=mcp; mode=direct"

_ans-badge   IN  TXT    "v=ans-badge1; version=v1.5.0;
    url=https://{tl_host}/v1/agents/{agentId}"

; High-assurance (AHP-managed, per ADR 010)
_ans-identity._tls IN TLSA 3 0 1 <sha256_of_identity_cert>

A.6. AIM Failure Report

{
  "event_type": "integrity_failure_detected",
  "event_timestamp": "2026-03-06T11:00:00Z",
  "worker_id": "id-C",
  "agent_host": "support.example.com",
  "ans_name": "ans://v1.5.0.support.example.com",
  "check": {
    "record_type": "_ans",
    "failure_type": "MISMATCH",
    "expected_value": "v=ans1; version=v1.5.0; ...",
    "actual_value": "v=ans1; version=v1.5.0;
      url=https://malicious-site.example.com/evil-card.json"
  }
}

A.7. Revocation Request and Response

{
  "reason": "CESSATION_OF_OPERATION",
  "comments": "Service is being retired."
}

The RA returns the DNS records the AHP must delete:¶

{
  "agentId": "550e8400-e29b-41d4-a716-446655440000",
  "ansName": "ans://v1.5.0.support.example.com",
  "status": "REVOKED",
  "reason": "CESSATION_OF_OPERATION",
  "revokedAt": "2026-03-20T14:00:00Z",
  "dnsRecordsToRemove": [
    { "name": "support.example.com",
      "type": "HTTPS", "purpose": "DISCOVERY" },
    { "name": "_443._tcp.support.example.com",
      "type": "TLSA", "purpose": "CERTIFICATE_BINDING" },
    { "name": "_ans.support.example.com",
      "type": "TXT", "purpose": "TRUST" },
    { "name": "_ans-badge.support.example.com",
      "type": "TXT", "purpose": "BADGE" }
  ]
}