The ai-safety.txt Domain AI Safety Declaration
draft-fane-ai-safety-txt-00

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,
              <https://www.rfc-editor.org/info/rfc2119>.

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

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", RFC 8615, May 2019,
              <https://www.rfc-editor.org/info/rfc8615>.

8.  Informative References

   [AI-TXT]   "AI.TXT: A Declaration File for AI Usage Preferences,
              Licensing, and Policy", 2026,
              <https://datatracker.ietf.org/doc/draft-car-ai-txt-
              wellknown/>.

   [AIPREF-VOCAB]
              IETF AI Preferences (AIPREF) Working Group, "A Vocabulary
              for Expressing AI Usage Preferences", 2026,
              <https://datatracker.ietf.org/doc/draft-ietf-aipref-
              vocab/>.

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,
              <https://www.rfc-editor.org/info/rfc9309>.

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]