| Internet-Draft | Agent Identity Document | October 2026 |
| Alla | Expires 4 May 2027 | [Page] |
Autonomous software agents increasingly act on the public internet with no name that a counterparty can check, no published party that answers for them, and no way to learn that an operator has withdrawn an agent. This document specifies the Agent Identity Document, a small JSON document served at a well-known URI on a hostname assigned to one agent, and the practices an identity provider follows when it hosts such names for operators who do not run their own domain.¶
The document records what the provider knows to be true (the hostname, its service endpoints and the identity's lifecycle status) separately from what the operator asserts (a description, a contact, a homepage, a public key), and publishes the provider's dated, expiring checks on the operator rather than a single trust level. Lifecycle status is distinct from availability. A suspended identity publishes a deliberately minimal document. Every identity is held by an accountable person or organisation; an agent is never itself an account holder, and agents are never given authority over DNS.¶
This document describes a practice in production at one provider. It is published so that the format can be reviewed, implemented by others and mapped onto related work, and it requests registration of a well-known URI suffix.¶
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 4 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
Websites solved a version of this problem years ago. A certificate says who a site is. A published security contact says where to report a problem. A revoked certificate stops being trusted everywhere at once. Software agents that call APIs, serve tools and receive webhooks on the open internet have none of this by default. They borrow their operator's credentials, run from addresses nobody can trace, and carry no name that another system can look up.¶
Several efforts address parts of the gap. The Agent Name Service [ANS0]
[I-D.narajala-courtney-ansv2] anchors an agent to a domain name whose
control its operator proves, and lets the operator hold separately proven
identities such as a decentralised identifier or a Legal Entity Identifier,
sealed in a transparency log. The A2A Agent Card [A2A] describes an
agent's capabilities at /.well-known/agent-card.json. The Agent Discovery
Protocol [I-D.pro-adp-agent-discovery] describes discovery metadata.
Web Bot Auth [I-D.ietf-webbotauth-httpsig-protocol] lets an agent sign its
requests with a key a verifier can fetch.¶
Each of these assumes the operator already has something: a domain, a certificate, a key directory. Most people who build agents have none of them, and have no wish to run DNS or PKI. This document describes the missing layer for them: an identity hosted by a provider, created in one request, with the name, TLS, service endpoints and a public record supplied by the provider, and with a person or organisation accountable for it from the first minute.¶
It also records four design positions that distinguish this format from related work:¶
Facts and assertions are kept apart. The provider publishes what it made true (name, endpoints, status) and labels what the operator merely claims.¶
Checks on the operator are itemised, dated and expiring. There is no level and no badge; each check says what was checked, how, by whom, when, and until when.¶
Lifecycle is not liveness. status records the operator's and
provider's decisions about the identity. It never reports whether the
agent is online.¶
A person stays accountable. An identity belongs to an account held by a natural person or legal entity. An agent acts under an account; it is never one. Agents never hold DNS or registrar authority.¶
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.¶
The terms "identity provider" and "provider" mean the party that assigns hostnames under a base domain it controls and serves Agent Identity Documents for them. "Operator" means the account holder responsible for an agent. "Relying party" means any system that reads an Agent Identity Document to decide how to treat an agent.¶
The provider controls a base domain. Each identity receives one identity hostname, a single DNS label under the base domain:¶
<slug>.<base-domain> e.g. alice.knownas.dev¶
Each service the identity offers receives a service hostname with the service label leading the base domain, so that every hostname is exactly one label below a name the provider can cover with a wildcard certificate:¶
<slug>.api.<base-domain> an HTTP API <slug>.mcp.<base-domain> a Model Context Protocol endpoint <slug>.hooks.<base-domain> inbound webhooks¶
The nested form api.<slug>.<base-domain> is NOT used: a wildcard
certificate covers exactly one label, and the nested form would require a
certificate per identity.¶
A <slug> MUST be a valid DNS label [RFC1035]: lowercase ASCII letters,
digits and hyphens, not beginning or ending with a hyphen. This specification
RECOMMENDS a minimum of 3 and a maximum of 63 characters. The provider MUST
refuse slugs that collide with its own infrastructure names (such as api,
mcp, hooks, www) and SHOULD refuse names that impersonate protected
brands, including when a brand appears as a word inside a longer slug
("combosquatting"). Refusal lists are the provider's; this document requires
only that they exist and are enforced before any DNS record is written.¶
An identity is created and held by an account. An account MUST be held by a natural person or a legal entity, and the provider MUST verify at minimum that the account holder controls the e-mail address used to create it. The provider MAY require a minimum age.¶
An agent MAY manage identities through a credential scoped to an account, and MAY be the thing that creates an identity. An agent MUST NOT be able to create an account. This keeps a person or organisation answerable for every identity, however it was created.¶
The Agent Identity Document is a JSON document [RFC8259] served over HTTPS [RFC9110] at the well-known URI [RFC8615]¶
https://<identity-hostname>/.well-known/agent-identity.json¶
Implementations that predate this document serve the same content at
/.well-known/agent.json; see Section 5.7.¶
The document MUST be served with Content-Type: application/json,
X-Content-Type-Options: nosniff and Access-Control-Allow-Origin: *, so
that a browser-based relying party can read it. The same headers MUST be sent
on a 404 response for an unallocated or deleted identity, so that a relying
party can distinguish "no such identity" from a network failure.¶
A relying party MUST treat a 404 at this URI as "no identity is published here", and MUST NOT treat it as evidence that the hostname was never allocated: a deleted identity's document is removed before its DNS records are, and a tombstoned name may still resolve to the provider for a time (Section 4).¶