OpenA2A

US info@opena2a.org

Security Individual Submission AI safety AI agents well-known URI prompt injection web content 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.

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 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 () exists to point at exactly that kind of external evidence.

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 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.

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 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.

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 . 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 .

Security Considerations

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.

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.

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.

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.

IANA Considerations This document requests that IANA register the "ai-safety.txt" well-known URI suffix in the "Well-Known URIs" registry established by , using the following template.

URI suffix:

ai-safety.txt

Change controller:

IETF

Specification document(s):

This document

Status:

permanent

Related information:

None

Normative References Informative References IETF AI Preferences (AIPREF) Working Group

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 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 and via HTTP header fields. A related proposal, , 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.

Acknowledgments This specification was authored in the open and benefits from review of its declaration model by the OpenA2A community.