| Internet-Draft | ai-safety.txt | July 2026 |
| Fane | Expires 7 January 2027 | [Page] |
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.¶
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.¶
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.¶
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 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.¶
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.¶
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.¶
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¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
This specification was authored in the open and benefits from review of its declaration model by the OpenA2A community.¶