Individual Submission A. Fane Internet-Draft OpenA2A Intended status: Informational 6 July 2026 Expires: 7 January 2027 The ai-safety.txt Domain AI Safety Declaration draft-fane-ai-safety-txt-00 Abstract This document defines ai-safety.txt, a plain-text declaration format that a domain publishes at a well-known location to communicate its AI-safety posture to autonomous agents and agent-driven browsers. Modeled on the robots.txt convention, an ai-safety.txt file lets a domain assert, in a machine-readable form, whether its content is safe for autonomous agent consumption, whether that content is hardened against prompt injection, and whether it is rendered consistently to human and agent user agents. The file also carries a security contact, a link to an external verification record, and the date the declaration was last verified. The declarations in an ai-safety.txt file are self-asserted by the publishing domain. This document specifies the file format and its well-known location, and it is explicit that a consuming agent treats a declaration as a hint rather than as proof, verifying it against independent evidence where such evidence is available. 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 7 January 2027. Fane Expires 7 January 2027 [Page 1] Internet-Draft ai-safety.txt July 2026 Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. File Format and Fields . . . . . . . . . . . . . . . . . . . 3 4. The Well-Known URI . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5.1. Declarations Are Self-Asserted . . . . . . . . . . . . . 5 5.2. Independent Verification . . . . . . . . . . . . . . . . 5 5.3. Cloaking and Consistent-Rendering . . . . . . . . . . . . 5 5.4. Transport Integrity . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 8. Informative References . . . . . . . . . . . . . . . . . . . 6 Appendix A. Related Work . . . . . . . . . . . . . . . . . . . . 7 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Autonomous AI agents and agent-driven browsers increasingly fetch, parse, and act on arbitrary web content on behalf of a user. Unlike a human reader, an agent may treat text on a page as instructions, follow links without judgment, and expose privileged tools or credentials to whatever it reads. This makes the safety posture of a page a first-order concern for the agent that consumes it, yet the web offers no machine-readable way for a domain to declare that posture. The Robots Exclusion Protocol [RFC9309] established a simple, durable pattern: a domain publishes a small plain-text file at a predictable location, and automated consumers fetch and honor it before acting. ai-safety.txt applies the same pattern to the agent era. A domain publishes a plain-text file that declares its AI-safety posture, and Fane Expires 7 January 2027 [Page 2] Internet-Draft ai-safety.txt July 2026 an agent fetches and checks that file before processing the domain's pages. It is a direct response to calls for web standards that describe AI-consumable content. An ai-safety.txt file is an Informational declaration, not a protocol exchange. Every field in it is self-asserted by the publishing domain: the domain is describing its own posture, and nothing in the file is independently proven by the act of publishing it. A consuming agent therefore SHOULD treat each declaration as a hint that informs risk decisions, not as a guarantee, and SHOULD verify a declaration against external evidence where such evidence is available. The Attestation field (Section 3) exists to point at exactly that kind of external evidence. 2. Conventions and Terminology 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. Domain The origin, identified by host name, that publishes an ai- safety.txt file describing its own AI-safety posture. Agent An AI system, including an agent-driven browser, that fetches and acts on web content on behalf of a user or organization. Consumer Any agent or tool that fetches an ai-safety.txt file and uses its declarations to inform a decision. Declaration The set of self-asserted fields carried in a domain's ai-safety.txt file. 3. File Format and Fields An ai-safety.txt file is a UTF-8 encoded plain-text file. Each field appears on its own line in the form "Field: value", where the field name is case-insensitive and is separated from its value by a colon and optional whitespace. Lines whose first non-whitespace character is "#" are comments and MUST be ignored. Consumers MUST ignore any field name they do not recognize, so that the format can be extended without breaking existing consumers. A field name SHOULD NOT appear more than once; if it does, a consumer MUST use the first occurrence. This document defines the following six fields. AI-Safe (boolean) Whether the domain asserts that its content is Fane Expires 7 January 2027 [Page 3] Internet-Draft ai-safety.txt July 2026 safe for autonomous agent consumption. A value of "true" asserts safety; "false" asserts that the domain does not make that claim. Injection-Protected (boolean) Whether the domain asserts that its content is hardened against prompt-injection payloads embedded in the page content it serves. Consistent-Rendering (boolean) Whether the domain declares that it serves identical content to human user agents and to agent user agents, that is, that it does not cloak by presenting different content to agents than to people. Contact (URI) A security or abuse contact for the domain, expressed as a URI, for example a "mailto:" or "https:" URI. Attestation (URI) A URI that links to an external verification record for the declaration, such as a registry verification record, enabling a consumer to check the domain's claims against independent evidence. Last-Verified (ISO 8601 date) The date on which the declaration was last verified, expressed as an ISO 8601 calendar date (for example, "2026-07-01"). Boolean fields take the value "true" or "false". A consumer that encounters any other value for a boolean field MUST treat that field as absent. All six fields are OPTIONAL; a consumer MUST tolerate the absence of any field and MUST NOT infer a value for a field that is not present. The following is an example ai-safety.txt file. # ai-safety.txt for example.com AI-Safe: true Injection-Protected: true Consistent-Rendering: true Contact: mailto:security@example.com Attestation: https://registry.example.org/verify/example.com Last-Verified: 2026-07-01 4. The Well-Known URI A domain that publishes a declaration MUST make it available at the path "/.well-known/ai-safety.txt" on that domain, following the well- known URI mechanism defined in [RFC8615]. A consumer constructs the request URI by appending "/.well-known/ai-safety.txt" to the domain's origin. Fane Expires 7 January 2027 [Page 4] Internet-Draft ai-safety.txt July 2026 The file SHOULD be served over HTTPS with the media type "text/ plain". A consumer that receives any response status other than a successful one, or that cannot parse the retrieved file, MUST behave as though no declaration exists for the domain. The registration of the "ai-safety.txt" suffix in the well-known URIs registry is requested in Section 6. 5. Security Considerations 5.1. Declarations Are Self-Asserted Every field in an ai-safety.txt file is asserted by the domain that publishes it. A malicious or compromised domain can publish a declaration that over-claims its posture, for example asserting "AI- Safe: true" and "Injection-Protected: true" while serving hostile content. A consumer MUST NOT treat a declaration as proof of the property it asserts, and MUST NOT relax its own defenses solely because a domain claims a favorable posture. A declaration is an input to a risk decision, not a substitute for one. 5.2. Independent Verification The Attestation field allows a domain to point at an external verification record, such as a registry verification record, that a consumer can check independently of the domain's own claims. Where an Attestation URI is present, a consumer SHOULD retrieve and evaluate it rather than relying on the self-asserted boolean fields alone. Because the Attestation URI is itself carried in a self- asserted file, a consumer MUST confirm that the referenced record actually corresponds to the domain in question and originates from a verifier the consumer trusts. 5.3. Cloaking and Consistent-Rendering A domain can serve different content to agents than to human visitors, a practice known as cloaking, in order to hide hostile content from human review. The Consistent-Rendering field lets a domain declare that it does not do this. A consumer SHOULD treat that declaration as testable: it can fetch a page as both a human- like and an agent-like user agent and compare the results. A mismatch between a "Consistent-Rendering: true" declaration and observed behavior is a strong negative signal and SHOULD override the declaration. Fane Expires 7 January 2027 [Page 5] Internet-Draft ai-safety.txt July 2026 5.4. Transport Integrity Because a declaration influences how a consumer processes a domain's content, an on-path attacker who can modify the ai-safety.txt response can influence that processing. Consumers SHOULD retrieve the file over HTTPS and MUST NOT treat a declaration retrieved over an unauthenticated channel as more trustworthy than one that was not retrieved at all. 6. IANA Considerations This document requests that IANA register the "ai-safety.txt" well- known URI suffix in the "Well-Known URIs" registry established by [RFC8615], using the following template. URI suffix: ai-safety.txt Change controller: IETF Specification document(s): This document Status: permanent Related information: None 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, May 2019, . 8. Informative References [AI-TXT] "AI.TXT: A Declaration File for AI Usage Preferences, Licensing, and Policy", 2026, . [AIPREF-VOCAB] IETF AI Preferences (AIPREF) Working Group, "A Vocabulary for Expressing AI Usage Preferences", 2026, . Fane Expires 7 January 2027 [Page 6] Internet-Draft ai-safety.txt July 2026 [RFC9309] Koster, M., Illyes, G., Zeller, H., and L. Sassman, "Robots Exclusion Protocol", RFC 9309, September 2022, . Appendix A. Related Work Several efforts define machine-readable declarations for AI-related metadata, and it is important to distinguish their scope from that of ai-safety.txt. The IETF AI Preferences working group [AIPREF-VOCAB] specifies a vocabulary for expressing how a site's content may be used by automated processing systems, for example for training, indexing, or inference, carried via the Robots Exclusion Protocol [RFC9309] and via HTTP header fields. A related proposal, [AI-TXT], registers a well-known "ai.txt" file for AI usage preferences, licensing, and policy. Those efforts govern whether and how a site's content may be used by AI systems: they are addressed to the operator of the AI system as consumer of content. The present document is complementary and orthogonal in scope: ai-safety.txt declares the domain's own safety posture toward agents that consume its content, namely whether the content is asserted safe for autonomous consumption, hardened against embedded prompt injection, and rendered identically to human and agent user agents. It expresses no usage, licensing, or training preference. A domain MAY publish both an AI usage preferences declaration and an ai-safety.txt declaration; they answer different questions and do not overlap. Where both are present, a consuming agent applies usage preferences to decide whether it may process the content and applies the ai-safety.txt declaration as one input, subject to the verification caveats in this document, to how cautiously it should do so. Appendix B. Acknowledgments This specification was authored in the open and benefits from review of its declaration model by the OpenA2A community. Author's Address Abdel Fane OpenA2A United States of America Email: info@opena2a.org Fane Expires 7 January 2027 [Page 7]